本文介绍如何用策略模式与组合模式替代强制实现的空抽象方法，通过将排除逻辑提取为可选的 Excludable 接口及其实现类，使子测量组件（如 Submeasure）按需装配行为，避免代码冗余与设计僵化。
本文介绍如何用策略模式与组合模式替代强制实现的空抽象方法，通过将排除逻辑提取为可选的 `excludable` 接口及其实现类，使子测量组件（如 `submeasure`）按需装配行为，避免代码冗余与设计僵化。
在构建可复用的医疗质量测量框架时，常需建模具有层级依赖关系的子测量（submeasure），例如 sub2 的人群数据完全派生自 sub1 的计算结果。此时若沿用传统继承式抽象设计——要求所有子类实现 Denominator 中的 _remove_exclusions() 等抽象方法——就会导致部分子类不得不提供无意义的空实现（如 pass），违背“里氏替换原则”，也损害可维护性与语义清晰度。
根本问题不在于“要不要排除”，而在于“谁负责排除、何时排除、如何排除”。解决方案是将行为从类结构中解耦，转为可插拔的组件。我们采用组合（Composition）+ 策略（Strategy）模式重构：
✅ 第一步：定义行为契约（接口），而非强制实现
from abc import ABC, abstractmethod
import pandas as pd
class Excludable(ABC):
"""定义排除操作的统一契约，不绑定具体实现"""
@abstractmethod
def remove_exclusions(self, df: pd.DataFrame) -> pd.DataFrame:
"""
对输入 DataFrame 执行排除逻辑（如过滤特定患者、剔除无效记录等）
返回处理后的新 DataFrame（保持不可变性最佳实践）
"""
...该接口清晰表达了“具备排除能力”的语义，且不侵入 Submeasure 的核心职责。
✅ 第二步：按需提供具体实现
class DefaultExclusion(Excludable):
"""标准排除实现示例：基于 patient_id 和 exclusion_flag 列过滤"""
def remove_exclusions(self, df: pd.DataFrame) -> pd.DataFrame:
if 'exclusion_flag' in df.columns:
return df[~df['exclusion_flag']].copy()
return df.copy() # 无排除标识时返回副本，确保安全性
class NoExclusion(Excludable):
"""显式表示‘无需排除’的哑实现，比 pass 更具可读性与可测试性"""
def remove_exclusions(self, df: pd.DataFrame) -> pd.DataFrame:
return df.copy()NoExclusion 的存在本身即是一种设计信号——它明确表达“此处跳过排除”这一业务意图，优于隐藏的 pass 或条件分支。
✅ 第三步：在 Submeasure 中以组合方式集成排除能力
class Submeasure(Denominator, Numerator, Stratification):
"""支持按需装配排除逻辑的子测量基类"""
def __init__(
self,
name: str,
data: list[pd.DataFrame],
exclusion_handler: Excludable | None = None
):
self.name = name
self.data = data
self.exclusion_handler = exclusion_handler # 可选依赖，非强制
def apply_exclusions(self) -> None:
"""安全执行排除：仅当 handler 存在时调用"""
if self.exclusion_handler is not None:
self.data = [
self.exclusion_handler.remove_exclusions(df)
for df in self.data
]关键改进：
-
exclusion_handler是构造时注入的可选依赖，默认为None； -
apply_exclusions()方法封装了空值检查，调用方无需关心是否已配置 handler； -
Submeasure不再继承Denominator的抽象方法，彻底消除Unneeded Abstract Method警告。
✅ 第四步：在具体测量类中差异化装配
class ASC(Measurement):
def __init__(
self,
sub1_data: list[pd.DataFrame],
sub2_data: list[pd.DataFrame] | None = None
):
super().__init__("ASC")
# sub1：需要独立排除逻辑 → 注入 DefaultExclusion
self.__sub1__ = _Sub_1(
name=self.get_name() + "_sub_1",
data=sub1_data,
exclusion_handler=DefaultExclusion()
)
# sub2：数据完全源自 sub1 结果 → 显式声明无需排除
self.__sub2__ = _Sub_2(
name=self.get_name() + "_sub_2",
data=sub2_data,
exclusion_handler=NoExclusion() # 或直接传 None，效果一致
)
def calculate(self) -> dict[str, pd.DataFrame]:
# 1. sub1 先执行完整流程（含排除）
sub1_results = self.__sub1__.calculate()
# 2. 派生 sub2 数据（利用 sub1 的 numerator 结果）
populace, stratification = self.__get_sub2_subset(sub1_results)
# 3. 将派生数据注入 sub2（此时 sub2 的 exclusion_handler 不会被触发）
self.__sub2__._set_sub1_subset((populace, stratification))
return {**sub1_results, **self.__sub2__.calculate()}⚠️ 注意事项与进阶建议
-
避免运行时类型判断：不要在
Submeasure内部用isinstance(self.exclusion_handler, NoExclusion)做分支，应由remove_exclusions()方法自身保证幂等性或轻量开销。 -
线程安全考虑：若
Excludable实现含状态（如缓存），需确保其线程安全；推荐无状态设计（如DefaultExclusion）。 -
扩展性增强：未来可轻松添加
CohortBasedExclusion或RuleEngineExclusion，只需实现Excludable接口，无需修改Submeasure。 -
测试友好性：单元测试中可轻松注入 Mock
Excludable，验证排除逻辑是否被正确调用或跳过。
这种设计将“是否需要排除”这一业务决策上移到对象创建阶段，而非编码到类契约中，既满足开闭原则（对扩展开放，对修改关闭），又显著提升代码的语义准确性与长期可演进性。
