Python面向对象设计原则:SOLID原则实战指南

classUserManager:"""既管理用户数据，又发送邮件，还处理日志——职责过多！"""def__init__(self, username):self.username = usernamedefsave_to_database(self):# 保存用户到数据库print(f"用户{self.username}已保存到数据库")defsend_welcome_email(self):# 发送欢迎邮件print(f"向{self.username}发送欢迎邮件")deflog_activity(self, activity):# 记录用户活动日志print(f"日志：用户{self.username}进行了{activity}操作")# 随着功能增加，这个类会越来越臃肿...

• • 如果数据库结构变了，要修改这个类
• • 如果邮件模板变了，也要修改这个类
• • 如果日志格式变了，还是要修改这个类
• • 一个地方出错，可能影响所有功能

classUser:"""只负责用户数据的表示"""def__init__(self, username):self.username = usernameclassUserRepository:"""只负责用户数据持久化"""defsave(self, user):print(f"用户{user.username}已保存到数据库")classEmailService:"""只负责发送邮件"""defsend_welcome_email(self, user):print(f"向{user.username}发送欢迎邮件")classLogger:"""只负责日志记录"""deflog(self, user, activity):print(f"日志：用户{user.username}进行了{activity}操作")# 使用示例user = User("小明")repo = UserRepository()email_service = EmailService()logger = Logger()repo.save(user)email_service.send_welcome_email(user)logger.log(user, "注册")

• • 每个类职责清晰，易于理解和维护
• • 修改数据库逻辑时，只需改UserRepository
• • 可以单独测试每个功能
• • 便于复用：EmailService可以用于其他需要发邮件的场景

• • 当发现一个类的方法可以明显分组到不同功能时
• • 当一个类需要频繁修改，但每次修改原因不同时
• • 在团队协作中，需要明确分工时

• • 不要过度拆分，把简单的事情复杂化
• • 一个类3-5个方法是比较合适的规模
• • 如果两个职责总是同时变化，可以考虑放在一起

classAreaCalculator:"""计算各种图形的面积——每新增一种图形都要修改这个类"""defcalculate_area(self, shape):if shape["type"] == "circle":return3.14 * shape["radius"] * shape["radius"]elif shape["type"] == "rectangle":return shape["width"] * shape["height"]elif shape["type"] == "triangle":return0.5 * shape["base"] * shape["height"]# 每增加一种新图形，就要在这里加一个elif分支else:raise ValueError("不支持的图形类型")# 使用示例calculator = AreaCalculator()circle = {"type": "circle", "radius": 5}rectangle = {"type": "rectangle", "width": 4, "height": 6}print(f"圆面积：{calculator.calculate_area(circle)}")print(f"矩形面积：{calculator.calculate_area(rectangle)}")

• • 每次支持新图形都要修改calculate_area方法
• • 修改可能引入bug，影响已有的功能
• • 方法会越来越长，难以维护

from abc import ABC, abstractmethodclassShape(ABC):"""图形抽象基类"""    @abstractmethoddefarea(self):passclassCircle(Shape):def__init__(self, radius):self.radius = radiusdefarea(self):return3.14 * self.radius * self.radiusclassRectangle(Shape):def__init__(self, width, height):self.width = widthself.height = heightdefarea(self):returnself.width * self.heightclassTriangle(Shape):def__init__(self, base, height):self.base = baseself.height = heightdefarea(self):return0.5 * self.base * self.heightclassAreaCalculator:"""现在这个类对修改关闭，对扩展开放"""defcalculate_area(self, shape):return shape.area()# 使用示例calculator = AreaCalculator()circle = Circle(5)rectangle = Rectangle(4, 6)triangle = Triangle(3, 4)print(f"圆面积：{calculator.calculate_area(circle)}")print(f"矩形面积：{calculator.calculate_area(rectangle)}")print(f"三角形面积：{calculator.calculate_area(triangle)}")# 新增图形时，只需新增类，不用修改已有代码classEllipse(Shape):def__init__(self, a, b):self.a = aself.b = bdefarea(self):return3.14 * self.a * self.bellipse = Ellipse(5, 3)print(f"椭圆面积：{calculator.calculate_area(ellipse)}")  # 无需修改AreaCalculator！

• • 新增功能时，原有代码保持稳定
• • 降低回归测试的成本
• • 代码结构更清晰，符合“高内聚、低耦合”

• • 当系统需要频繁添加新功能时
• • 在框架或库的设计中特别重要
• • 当修改已有代码风险较高时

• • 使用抽象（接口或抽象类）
• • 使用策略模式、模板方法模式
• • 依赖注入

classRectangle:def__init__(self, width, height):self.width = widthself.height = heightdefset_width(self, width):self.width = widthdefset_height(self, height):self.height = heightdefarea(self):returnself.width * self.heightclassSquare(Rectangle):"""正方形继承矩形——看似合理，实则违反LSP"""def__init__(self, side):super().__init__(side, side)defset_width(self, width):self.width = widthself.height = width  # 这里改变了父类的行为！defset_height(self, height):self.height = heightself.width = height  # 这里改变了父类的行为！# 测试函数deftest_area(rectangle):"""这个函数期望Rectangle能正常工作"""    rectangle.set_width(5)    rectangle.set_height(4)    expected = 20# 5 * 4    actual = rectangle.area()assert actual == expected, f"期望{expected}，实际{actual}"# 使用父类时正常rect = Rectangle(0, 0)test_area(rect)  # 通过# 使用子类时出错！square = Square(0)test_area(square)  # 断言错误！实际得到16，不是20

• • Square改变了set_width和set_height的语义
• • 父类的使用者（test_area函数）预期宽度和高度独立设置
• • 子类破坏了父类的契约

classShape:"""使用更通用的基类"""    @abstractmethoddefarea(self):passclassRectangle(Shape):def__init__(self, width, height):self.width = widthself.height = heightdefarea(self):returnself.width * self.heightclassSquare(Shape):def__init__(self, side):self.side = sidedefarea(self):returnself.side * self.side# 或者：如果不需设置宽度/高度，可以这样设计classResizableRectangle(Rectangle):"""明确表示这是可调整大小的矩形"""defresize(self, width, height):self.width = widthself.height = height# 现在所有子类都能正确替换父类shapes = [Rectangle(5, 4), Square(5)]for shape in shapes:print(f"图形面积：{shape.area()}")

• • 子类不会破坏父类的预期行为
• • 多态性可以安全使用
• • 代码更健壮，减少隐藏bug

• • 设计类继承层次时
• • 使用多态和依赖注入时
• • 编写通用算法时

1. 1. 前置条件不能强化：子类不能要求比父类更严格的条件
2. 2. 后置条件不能弱化：子类不能提供比父类更弱的承诺
3. 3. 不变量必须保持：父类的不变量（数据一致性）在子类中必须保持
4. 4. 历史约束：子类不能添加父类没有的状态变化

classWorker:"""一个庞大的接口，包含所有可能的工作"""    @abstractmethoddefwork(self):pass    @abstractmethoddefeat(self):pass    @abstractmethoddefsleep(self):pass    @abstractmethoddefcode(self):pass    @abstractmethoddefdesign(self):pass    @abstractmethoddeftest(self):passclassProgrammer(Worker):"""程序员被迫实现所有方法，即使有些用不到"""defwork(self):print("程序员在工作")defeat(self):print("程序员在吃饭")defsleep(self):print("程序员在睡觉")defcode(self):print("程序员在写代码")defdesign(self):  # 程序员可能不擅长设计，但被迫实现print("程序员在设计...（其实不擅长）")deftest(self):  # 也可能不是测试专家print("程序员在测试...（草草了事）")classDesigner(Worker):"""设计师也被迫实现所有方法"""# ... 类似地，设计师可能不擅长写代码

• • 客户端（Programmer）被迫依赖不需要的方法
• • 接口改变时，所有客户端都要修改
• • 产生“空实现”或抛出NotImplementedError

# 拆分为多个特定接口classWorkable:    @abstractmethoddefwork(self):passclassEatable:    @abstractmethoddefeat(self):passclassSleepable:    @abstractmethoddefsleep(self):passclassCodable:    @abstractmethoddefcode(self):passclassDesignable:    @abstractmethoddefdesign(self):passclassTestable:    @abstractmethoddeftest(self):pass# 程序员只需要实现相关的接口classProgrammer(Workable, Eatable, Sleepable, Codable):defwork(self):print("程序员在工作")defeat(self):print("程序员在吃饭")defsleep(self):print("程序员在睡觉")defcode(self):print("程序员优雅地写代码")classDesigner(Workable, Eatable, Sleepable, Designable):defwork(self):print("设计师在工作")defeat(self):print("设计师在吃饭")defsleep(self):print("设计师在睡觉")defdesign(self):print("设计师创作精美设计")classTester(Workable, Eatable, Sleepable, Testable):defwork(self):print("测试员在工作")defeat(self):print("测试员在吃饭")defsleep(self):print("测试员在睡觉")deftest(self):print("测试员进行全面测试")# 使用示例programmer = Programmer()designer = Designer()tester = Tester()programmer.code()  # 程序员专注写代码designer.design()  # 设计师专注设计tester.test()      # 测试员专注测试# 每个类只关注自己的核心能力

• • 客户端只依赖需要的接口
• • 接口更小、更专注
• • 更容易理解、实现和维护
• • 减少接口之间的耦合

• • 当接口变得臃肿时
• • 当不同客户端需要接口的不同子集时
• • 在设计插件系统或框架时

• • 接口继承（多个小接口）
• • 适配器模式
• • 默认方法（Python 3.4+的@abstractmethod）

classLightBulb:"""具体的灯泡类"""defturn_on(self):print("灯泡亮了")defturn_off(self):print("灯泡灭了")classSwitch:"""开关直接依赖具体的灯泡类"""def__init__(self):self.bulb = LightBulb()  # 直接依赖具体实现defoperate(self, state):if state == "on":self.bulb.turn_on()elif state == "off":self.bulb.turn_off()# 问题：如果我想换LED灯怎么办？要修改Switch类classLEDLight:defturn_on(self):print("LED灯亮了")defturn_off(self):print("LED灯灭了")# Switch不能直接使用LEDLight，必须修改代码

• • Switch紧耦合于LightBulb
• • 难以替换为其他类型的灯
• • 违反开闭原则

from abc import ABC, abstractmethodclassSwitchable(ABC):"""抽象接口：可开关的设备"""    @abstractmethoddefturn_on(self):pass    @abstractmethoddefturn_off(self):passclassLightBulb(Switchable):"""具体实现：灯泡"""defturn_on(self):print("💡 灯泡亮了")defturn_off(self):print("💡 灯泡灭了")classLEDLight(Switchable):"""具体实现：LED灯"""defturn_on(self):print("🔦 LED灯亮了")defturn_off(self):print("🔦 LED灯灭了")classFan(Switchable):"""具体实现：风扇"""defturn_on(self):print("🌀 风扇转了")defturn_off(self):print("🌀 风扇停了")classSwitch:"""开关依赖抽象接口，而不是具体实现"""def__init__(self, device: Switchable):  # 依赖注入self.device = devicedefoperate(self, state):if state == "on":self.device.turn_on()elif state == "off":self.device.turn_off()# 使用示例：可以轻松切换不同设备bulb = LightBulb()led = LEDLight()fan = Fan()switch1 = Switch(bulb)switch2 = Switch(led)switch3 = Switch(fan)switch1.operate("on")  # 输出：💡 灯泡亮了switch2.operate("on")  # 输出：🔦 LED灯亮了switch3.operate("on")  # 输出：🌀 风扇转了# 新增设备类型时，无需修改Switch类classHeater(Switchable):defturn_on(self):print("🔥 加热器启动了")defturn_off(self):print("🔥 加热器关闭了")heater = Heater()switch4 = Switch(heater)switch4.operate("on")  # 输出：🔥 加热器启动了

• • 高层模块（Switch）不依赖低层模块的具体实现
• • 系统更灵活，易于扩展和维护
• • 便于单元测试（可以注入模拟对象）

• • 当模块需要支持多种实现时
• • 在需要解耦的系统中
• • 在需要可测试性的代码中

• • 依赖注入（构造函数注入、属性注入）
• • 服务定位器模式
• • 控制反转容器

• • SRP是基础：一个类职责单一，才容易扩展（OCP）和替换（LSP）
• • OCP和LSP保证了继承体系的稳定性
• • ISP让接口更精细，便于实现DIP
• • DIP是最终目标：通过抽象实现松耦合

• • 小型工具脚本：过度设计反而增加复杂度
• • 原型开发：快速验证想法更重要
• • 内部使用的一次性代码

• • 核心业务逻辑
• • 公共库和框架
• • 长期维护的项目
• • 团队协作的大型项目

1. 1. 先让代码工作：功能正确是第一位的
2. 2. 识别痛点：当修改困难、bug频发时，回顾SOLID原则
3. 3. 小步重构：每次只改进一个最痛的点
4. 4. 保持测试：确保重构不破坏原有功能

classReportGenerator:defgenerate_report(self, data, report_type):if report_type == "pdf":# 生成PDF报告self.generate_pdf(data)self.send_email(data, "pdf")self.save_to_database(data, "pdf")elif report_type == "excel":# 生成Excel报告self.generate_excel(data)self.send_email(data, "excel")self.save_to_database(data, "excel")elif report_type == "html":# 生成HTML报告self.generate_html(data)self.send_email(data, "html")self.save_to_database(data, "html")defgenerate_pdf(self, data):print("生成PDF报告")defgenerate_excel(self, data):print("生成Excel报告")defgenerate_html(self, data):print("生成HTML报告")defsend_email(self, data, report_type):print(f"发送{report_type}报告邮件")defsave_to_database(self, data, report_type):print(f"保存{report_type}报告到数据库")

1. 1. 这个类违反了哪个原则最严重？
2. 2. 你会如何拆分这个类？
3. 3. 如何让它更容易扩展新报告类型？

1. 1. SRP：专注才能专业
2. 2. OCP：拥抱变化，但不破坏稳定
3. 3. LSP：继承是“增强”，不是“变异”
4. 4. ISP：小而美的接口
5. 5. DIP：面向抽象编程

1. 1. 从模仿开始：多读优秀开源项目的代码
2. 2. 小步前进：每次只关注改进一个方面
3. 3. 不怕犯错：即使违反了原则，只要代码能工作，就是进步
4. 4. 定期回顾：过段时间回头看自己的代码，会有新的感悟