本文介绍通过查找表（lookup table）和策略模式等 oop 手段，消除硬编码的 if/else 或 switch 逻辑，提升代码可维护性与扩展性。
本文介绍通过查找表（lookup table）和策略模式等 oop 手段，消除硬编码的 if/else 或 switch 逻辑，提升代码可维护性与扩展性。
在实际开发中，当业务需要根据产品类型（如 DVD、图书、家具）动态渲染不同字段时，直接使用 if-elseif-else 或 switch 不仅违反开闭原则（OCP），还导致逻辑分散、难以测试和扩展。推荐采用数据驱动 + 面向对象设计的方式重构，核心思路是：将行为差异外化为配置或对象，而非控制流分支。
✅ 推荐方案一：轻量级查找表（Lookup Table）
适用于属性映射简单、无需复杂行为的场景。将产品类型与字段名、单位等元信息预先定义为关联数组，运行时查表取值：
<?php
$lookup = [
'DVD' => ['field' => 'size', 'unit' => 'MB'],
'Furniture'=> ['field' => 'dimensions', 'unit' => ''],
'Book' => ['field' => 'weight', 'unit' => 'Kg'],
];
// 安全访问（避免未定义类型导致 Notice）
if (isset($lookup[$product['product_type']])) {
$config = $lookup[$product['product_type']];
echo "<p>{$config['field']}:" . ($product[$config['field']] ?? '') . "{$config['unit']}</p>";
} else {
echo "<p>Unknown product type: {$product['product_type']}</p>";
}
?>⚠️ 注意事项：
- 必须校验 $product['product_type'] 是否存在于 lookup 中，防止 Undefined array key 错误；
- 字段名应统一命名（如 dimensions 而非原文中的 dimentions 拼写错误），确保健壮性；
- 单位（unit）为空字符串时可省略拼接，增强可读性。
✅ 推荐方案二：策略模式（Strategy Pattern）
当每类产品需执行差异化逻辑（如格式化、验证、计算）时，应升级为面向对象设计：
<?php
interface ProductRenderer {
public function render(array $product): string;
}
class DvdRenderer implements ProductRenderer {
public function render(array $product): string {
return "<p>Size: {$product['size']}MB</p>";
}
}
class FurnitureRenderer implements ProductRenderer {
public function render(array $product): string {
return "<p>Dimensions: {$product['dimensions']}</p>";
}
}
class BookRenderer implements ProductRenderer {
public function render(array $product): string {
return "<p>Weight: {$product['weight']}Kg</p>";
}
}
// 渲染器工厂（解耦类型判断）
class RendererFactory {
private static $mappings = [
'DVD' => DvdRenderer::class,
'Furniture'=> FurnitureRenderer::class,
'Book' => BookRenderer::class,
];
public static function getRenderer(string $type): ProductRenderer {
$class = self::$mappings[$type] ?? null;
if (!$class || !class_exists($class)) {
throw new InvalidArgumentException("Unsupported product type: $type");
}
return new $class();
}
}
// 使用示例
try {
$renderer = RendererFactory::getRenderer($product['product_type']);
echo $renderer->render($product);
} catch (InvalidArgumentException $e) {
echo "<p>Error: {$e->getMessage()}</p>";
}
?>该设计优势显著：
- 新增产品类型只需新增一个 ProductRenderer 实现类，并在工厂中注册，无需修改现有逻辑；
- 每个渲染器职责单一、可独立单元测试；
- 类型判断被封装在工厂内，上层代码完全无条件语句。
✅ 总结
| 方案 | 适用场景 | 扩展性 | 可测试性 | 复杂度 |
|---|---|---|---|---|
| 查找表 | 字段映射简单、无业务逻辑 | ★★☆ | ★★☆ | ★☆☆ |
| 策略模式 | 各类型存在差异化行为（格式化、校验、计算等） | ★★★ | ★★★ | ★★☆ |
无论选择哪种方式，本质都是将“变化点”（产品类型 → 行为）从控制流中剥离，转为数据或对象。这不仅满足 recruiter 提出的“避免条件语句”要求，更使系统更符合 SOLID 原则，为后续迭代打下坚实基础。
