如何通过组合模式消除无用的抽象方法：解耦排除逻辑的最佳实践-Python教程-PHP中文网

如何通过组合模式消除无用的抽象方法：解耦排除逻辑的最佳实践

本文介绍如何用策略模式与组合模式替代强制实现的空抽象方法，通过将排除逻辑提取为可选的 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，验证排除逻辑是否被正确调用或跳过。