代码重构：优化复杂函数与消除Switch语句

本文旨在探讨如何通过应用SOLID原则和清洁代码实践，对包含复杂条件逻辑和switch语句的函数进行重构。我们将重点介绍如何利用提前返回、数据映射以及单一职责原则来简化代码结构、提高可读性与可维护性，从而消除冗余的switch语句，并使函数职责更加清晰。

优化复杂函数的策略与实践

在软件开发中，我们经常会遇到包含复杂条件逻辑、多重判断以及冗长switch语句的函数。这类函数通常难以阅读、理解和维护，并且容易违反单一职责原则（srp）和开放/封闭原则（ocp）。本教程将以一个具体的php函数为例，演示如何通过一系列重构技巧来提升代码质量。

原始函数execute存在以下主要问题：

1. 冗长的switch语句： 根据饮品类型判断价格并进行校验，导致代码重复且难以扩展。
2. 多层嵌套的条件判断： if语句和switch语句的组合导致代码层级深，可读性差。
3. 职责不明确： 函数内部既处理饮品类型校验，又处理金额校验，还处理糖量校验和输出信息。

我们的目标是使函数更简洁、更易于理解和修改。

1. 采用提前返回（Guard Clauses）简化条件逻辑

原始代码中存在多层嵌套的if语句，例如检查饮品类型是否合法。通过使用“提前返回”（Guard Clauses）模式，我们可以将不符合条件的逻辑提前终止，从而减少代码的嵌套深度，使主流程更加清晰。

重构前：

if (in_array($this->drinkType, $this->allowedDrinkTypes)) {
// ... 大量业务逻辑 ...
} else {
$output->writeln('The drink type should be tea, coffee or chocolate');
return 0;
}

重构后：

if (!in_array($this->drinkType, $this->allowedDrinkTypes)) {
$output->writeln('The drink type should be tea, coffee or chocolate');
return 0; // 不符合条件，立即返回
}
// ... 主流程代码，无需嵌套 ...

这种模式使得代码的阅读者能够更快地理解函数的退出条件，而无需深入到多层嵌套中。

2. 消除Switch语句：利用数据结构进行映射

原始函数中最大的痛点是根据饮品类型判断价格的switch语句。这种结构违反了开放/封闭原则（OCP），因为每当需要添加新的饮品类型时，都必须修改这个switch语句。更好的做法是使用数据结构（如关联数组或映射表）来存储这些关系。

重构前（Switch语句）：

switch ($this->drinkType) {
case 'tea':
if ($money < 0.4) { /* ... */ } break;
case 'coffee':
if ($money < 0.5) { /* ... */ } break;
case 'chocolate':
if ($money < 0.6) { /* ... */ } break;
}

重构后（使用映射表）：

$drinkCosts = [
'tea' => 0.4,
'coffee' => 0.5,
'chocolate' => 0.6
];
// 可以将 $drinkCosts 作为类成员变量或通过依赖注入管理
// $drinkCost = $this->drinkCosts[$this->drinkType]; // 如果是类成员变量
$drinkCost = $drinkCosts[$this->drinkType];
if ($money < $drinkCost) {
$output->writeln('The ' . $this->drinkType . ' costs ' . $drinkCost);
return 0;
}

通过将饮品类型和其价格的映射关系提取到一个数组中，我们实现了以下好处：

• 可扩展性： 添加新的饮品类型只需修改$drinkCosts数组，而无需改动核心逻辑。
• 可读性： 价格信息集中管理，一目了然。
• 单一职责： execute函数不再负责“知道”每种饮品的具体价格，它只负责“查询”价格。

3. 明确函数职责与单一职责原则（SRP）

在原始代码中，hasCorrectSugars用于校验糖量，而checkSugars用于输出订单信息。虽然它们都与“糖”相关，但职责不同。hasCorrectSugars是一个纯粹的校验函数，返回布尔值；而checkSugars是一个副作用函数，负责输出。这种分离是符合单一职责原则的良好实践。

原始hasCorrectSugars的优化：

原函数已经很简洁，但可以进一步简化返回语句：

protected function hasCorrectSugars($input): bool
{
$sugars = $input->getArgument('sugars');
// 直接返回布尔表达式的结果
return ($sugars >= $this->minSugars && $sugars <= $this->maxSugars);
}

在execute函数中，同样应用提前返回来处理糖量校验：

if (!$this->hasCorrectSugars($input)) {
$output->writeln('The number of sugars should be between 0 and 2');
return 0;
}
// 校验通过后，再调用输出函数
$this->checkSugars($input, $output);

通过这种方式，execute函数在调用checkSugars之前，已经确保了糖量的合法性，逻辑流更加清晰。

4. 完整的重构示例

结合上述策略，重构后的execute函数将变得更加简洁、可读且易于维护：

use Symfony\Component\Console\Input\InputInterface;
use Symfony\Component\Console\Output\OutputInterface;
// 假设这是某个Command类或类似结构中的方法
class DrinkOrderProcessor
{
protected string $drinkType;
protected array $allowedDrinkTypes = ['tea', 'coffee', 'chocolate']; // 示例
protected int $minSugars = 0; // 示例
protected int $maxSugars = 2; // 示例
// 假设 setDrinkType, isExtraHot 等方法已存在
protected function setDrinkType(InputInterface $input): void
{
$this->drinkType = $input->getArgument('drinkType'); // 假设有此参数
}
protected function hasCorrectSugars(InputInterface $input): bool
{
$sugars = $input->getArgument('sugars');
return ($sugars >= $this->minSugars && $sugars <= $this->maxSugars);
}
protected function checkSugars(InputInterface $input, OutputInterface $output): void
{
$sugars = $input->getArgument('sugars');
$output->write('You have ordered a ' . $this->drinkType);
// 假设 isExtraHot 负责输出额外信息
// $this->isExtraHot($input, $output);
$output->write(' with ' . $sugars . ' sugars');
if ($sugars > 0) {
$output->write(' (stick included)');
}
$output->writeln('');
}
/**
* 执行饮品订单处理的主方法
*
* @param InputInterface $input
* @param OutputInterface $output
* @return int 返回0表示失败或退出，返回1表示成功（根据实际CLI规范）
*/
protected function execute(InputInterface $input, OutputInterface $output): int
{
$this->setDrinkType($input);
// 1. 校验饮品类型，不合法则提前返回
if (!in_array($this->drinkType, $this->allowedDrinkTypes)) {
$output->writeln('The drink type should be tea, coffee or chocolate');
return 0;
}
// 2. 使用映射表管理饮品价格，消除switch语句
$drinkCosts = [
'tea' => 0.4,
'coffee' => 0.5,
'chocolate' => 0.6
];
// 检查饮品类型是否存在于价格表中，避免访问不存在的键
if (!isset($drinkCosts[$this->drinkType])) {
$output->writeln('Error: Price for ' . $this->drinkType . ' is not defined.');
return 0;
}
$money = (float)$input->getArgument('money'); // 确保金额是浮点数
$drinkCost = $drinkCosts[$this->drinkType];
// 3. 校验金额，不足则提前返回
if ($money < $drinkCost) {
$output->writeln('The ' . $this->drinkType . ' costs ' . $drinkCost);
return 0;
}
// 4. 校验糖量，不合法则提前返回
if (!$this->hasCorrectSugars($input)) {
$output->writeln('The number of sugars should be between 0 and 2');
return 0;
}
// 5. 所有校验通过，执行订单确认输出
$this->checkSugars($input, $output);
// 根据命令行工具的惯例，通常0表示成功，非0表示失败。
// 如果这里表示成功完成，则应返回0。如果0表示失败，则应返回1。
// 根据原始代码，所有错误路径都返回0，因此这里也保持返回0。
// 但更规范的做法是，成功返回0，失败返回非0。
return 0; // 假设0表示成功执行并退出
}
}

注意事项与进一步优化

1. 返回值约定： 在命令行工具中，return 0通常表示成功，非零值表示错误。原始代码中所有错误和成功路径都返回0，这可能会引起混淆。建议根据实际CLI规范进行调整，例如成功返回0，失败返回1或其他错误码，或者抛出异常来处理错误。
2. 依赖注入： drinkCosts可以作为类的一个成员变量，甚至通过构造函数注入，以提高灵活性和可测试性。
3. 错误处理： 对于更复杂的应用，仅仅通过writeln输出错误信息可能不足。可以考虑使用日志系统或抛出更具体的异常。
4. 策略模式： 对于不同饮品类型有更复杂、差异化的逻辑时（例如，不同饮品有不同的配料、制作流程），可以考虑引入策略模式来进一步解耦，而不是简单地通过映射表来处理。

总结

通过上述重构，我们成功地将一个复杂且难以维护的函数转化为一个结构清晰、职责明确、易于扩展和理解的代码段。核心技巧包括：

• 使用提前返回（Guard Clauses） 减少嵌套，提高代码可读性。
• 利用数据结构（如映射表）替代switch语句，遵循开放/封闭原则，使代码更易于扩展。
• 坚持单一职责原则（SRP），确保每个函数只做一件事，提高代码模块化程度。

这些实践不仅提升了当前代码的质量，也为未来的功能迭代和维护奠定了坚实的基础。