依赖倒置原则（DIP）应用疑问：场景适配与通用适用性

你对DIP的理解和落地做得很到位——通过抽象基类PricesData隔离高层服务HistoricalPricesService与具体数据实现，确实让输入扩展变得非常灵活，新增数据源只需要实现抽象类即可，高层代码完全不用修改，这正是DIP的核心价值。

下面针对你的两个问题逐一解答：

1. 是否应始终使用DIP？ #

答案是不需要。DIP是解决依赖耦合、需求易变场景的工具，并非所有场景都要硬套：

• 如果模块逻辑极简单，比如一个仅读取本地固定文件的小工具，未来几乎不会变更数据源，强行引入抽象反而会增加代码复杂度，完全没必要。
• 只有当你预判到依赖会变化（比如未来可能新增数据库、第三方API数据源），或者需要解耦测试（比如用MockData替代真实API做单元测试）时，DIP的价值才会真正体现。
• 简言之：用不用DIP，核心看你是否需要应对未来的变化，或是是否需要降低模块间的耦合度。

2. "至少三个易变输入/输出时才用DIP"是不是合理概括？ #

这个说法太过绝对，并不合理：

• 哪怕只有1个易变依赖，只要这个依赖未来有变更可能，DIP就有价值。比如你当前的场景，虽然只有API和Mock两个数据源，但如果未来要新增数据库数据源，提前用DIP做好抽象，后续扩展成本会极低。
• 反过来，如果有多个依赖但完全不会变化，强行用DIP只会造成冗余。
• 核心判断标准不是数量，而是依赖的易变性和模块解耦的需求。

代码优化小建议（可选） #

你的代码已经很规范了，提个细节优化：可以把get_data的返回类型定义在抽象基类中，让所有实现类的接口更统一：

from abc import ABC, abstractmethod
import pandas as pd

class PricesData(ABC):
    @abstractmethod
    def get_data(self) -> tuple[bool, pd.DataFrame]:
        pass

# 后续实现类保持原有逻辑即可...

内容的提问来源于stack exchange，提问作者abd klaib