本文介绍如何将重复结构的多层 if-elif 链重构为简洁、可维护的循环结构，通过提取共性（验证函数与搜索值）并使用元组列表驱动执行流程，避免代码冗余并提升扩展性。
本文介绍如何将重复结构的多层 if-elif 链重构为简洁、可维护的循环结构，通过提取共性（验证函数与搜索值）并使用元组列表驱动执行流程，避免代码冗余并提升扩展性。
在实际开发中，当面对多个具有相同执行模式但仅参数或验证逻辑不同的条件分支时（如按 Hostname、MAC 或 IP 分别搜索），硬编码多个 if/elif 不仅冗余，还难以维护和扩展。理想方案是识别变化点与不变骨架，将其解耦。
上述代码中，三个分支的共性非常清晰：
- 均调用 extract_blocks(app.conf_file_path) 获取待搜索的数据块；
- 均使用 filter(lambda a:
in a, blocks) 进行子串匹配； - 均在验证通过后立即打印结果并终止流程；
- 差异仅在于：验证函数（Hostname_Validation / MAC_Validation / IP_Validation）和对应的搜索字段值（search_option.Hostname / .MAC / .IP）。
因此，可将这对“验证函数–搜索值”封装为元组序列，并用单次 for 循环遍历：
def search_select(search_option: Searching_section):
# 定义验证策略：(验证函数, 对应字段值)
strategies = [
(Hostname_Validation, search_option.Hostname),
(MAC_Validation, search_option.MAC),
(IP_Validation, search_option.IP),
]
for validate_func, search_value in strategies:
if validate_func(search_value):
blocks, _ = extract_blocks(app.conf_file_path)
results = [block for block in blocks if search_value in block]
print(results)
return # 找到首个匹配即退出，符合原逻辑语义
# 可选：所有验证均失败时的兜底处理（例如抛出异常或返回空列表）
print("No valid search criterion provided.")
✅ 优势说明：
- 消除重复：extract_blocks 和 filter 逻辑只写一次；
- 易于扩展：新增搜索维度（如 VLAN、Port）只需在 strategies 列表末尾追加一行元组；
- 职责清晰：验证逻辑与执行逻辑分离，符合单一职责原则；
- 语义明确：return 确保短路执行，与原 if/elif 链行为完全一致。
⚠️ 注意事项：
- 验证函数必须接受单个参数且返回布尔值；
- 若需支持“多条件同时生效”（而非短路），应移除 return 并累积结果；
- 生产环境中建议对 search_value 为空字符串或 None 做预判（当前 Union[str, None] 类型已涵盖，但验证函数内部应妥善处理）；
- filter() 返回迭代器，直接 list(...) 可能引发内存压力——示例中改用列表推导式 [] 更直观，也便于后续调试或修改为生成器。
这种“策略列表 + 循环分发”的模式，是重构条件分支的经典手法，适用于配置驱动、规则引擎、表单校验等众多场景。
