当前位置:首页>python>Python面向对象设计——SOLID原则

Python面向对象设计——SOLID原则

  • 2026-10-11 08:22:11
Python面向对象设计——SOLID原则

一、什么是SOLID原则?

SOLID 是面向对象设计的五个基本原则的缩写,由 Robert C. Martin("Uncle Bob")提出。这些原则指导我们设计出可维护、可扩展、可复用的软件系统。

缩写
原则
中文名称
S
Single Responsibility Principle
单一职责原则
O
Open/Closed Principle
开闭原则
L
Liskov Substitution Principle
里氏替换原则
I
Interface Segregation Principle
接口隔离原则
D
Dependency Inversion Principle
依赖倒置原则

二、S:单一职责原则

一个类应该只有一个引起它变化的原因。 也就是说,一个类应该只负责一项职责。

2.1 违反原则的示例

classUser:"""用户类同时负责数据存储和业务逻辑"""def__init__(self, name, email):self.name = nameself.email = emaildefsave_to_database(self):"""保存到数据库"""print(f"保存用户 {self.name} 到数据库")defsend_welcome_email(self):"""发送欢迎邮件"""print(f"发送欢迎邮件到 {self.email}")defvalidate_email(self):"""验证邮箱格式"""return'@'inself.email and'.'inself.email# 问题:修改邮件发送逻辑会影响用户类,修改数据库逻辑也会影响用户类

2.2 遵循原则的改进

classUser:"""用户类只负责用户数据"""def__init__(self, name, email):self.name = nameself.email = emailclassUserRepository:"""负责用户数据持久化"""defsave(self, user):print(f"保存用户 {user.name} 到数据库")classEmailService:"""负责邮件发送"""defsend_welcome_email(self, email, name):print(f"发送欢迎邮件到 {email}")classEmailValidator:"""负责邮箱验证"""    @staticmethoddefis_valid(email):return'@'in email and'.'in email# 使用user = User("张三", "zhangsan@example.com")if EmailValidator.is_valid(user.email):    UserRepository().save(user)    EmailService().send_welcome_email(user.email, user.name)

三、O:开闭原则

对扩展开放,对修改关闭。 软件实体(类、模块、函数等)应该可以扩展,但不应该修改其源代码。

3.1 违反原则的示例

classDiscountCalculator:defcalculate(self, customer_type, price):if customer_type == "regular":return price * 0.9elif customer_type == "vip":return price * 0.8elif customer_type == "gold":return price * 0.7# 添加新客户类型需要修改这个类 ❌# 问题:每增加一种客户类型,都要修改这个类

3.2 遵循原则的改进

from abc import ABC, abstractmethodclassDiscountStrategy(ABC):"""折扣策略接口"""    @abstractmethoddefcalculate(self, price):passclassRegularDiscount(DiscountStrategy):defcalculate(self, price):return price * 0.9classVIPDiscount(DiscountStrategy):defcalculate(self, price):return price * 0.8classGoldDiscount(DiscountStrategy):defcalculate(self, price):return price * 0.7# 新增客户类型,只需添加新类,无需修改现有代码 ✅classSilverDiscount(DiscountStrategy):defcalculate(self, price):return price * 0.85classDiscountCalculator:def__init__(self, strategy: DiscountStrategy):self.strategy = strategydefcalculate(self, price):returnself.strategy.calculate(price)# 使用calculator = DiscountCalculator(VIPDiscount())print(calculator.calculate(100))  # 80

四、L:里氏替换原则

子类必须能够替换它们的基类。 派生类必须能够完全替代基类,而不影响程序的正确性。

4.1 违反原则的示例

classBird:deffly(self):return"我在飞"classPenguin(Bird):deffly(self):raise Exception("企鹅不会飞")  # ❌ 不能替代 Birddefmake_bird_fly(bird: Bird):return bird.fly()# 期望所有 Bird 都能飞make_bird_fly(Penguin())  # 抛出异常,违反了里氏替换原则

4.2 遵循原则的改进

from abc import ABC, abstractmethodclassBird(ABC):    @abstractmethoddefmove(self):passclassFlyingBird(Bird):defmove(self):return"我在飞"classSwimmingBird(Bird):defmove(self):return"我在游"classSparrow(FlyingBird):passclassPenguin(SwimmingBird):pass# 使用正确的类型替换defmake_move(bird: Bird):return bird.move()print(make_move(Sparrow()))   # 我在飞print(make_move(Penguin()))   # 我在游

五、I:接口隔离原则

客户端不应该被迫依赖它们不使用的接口。 多个专用的接口要好于一个宽泛的接口。

5.1 违反原则的示例

classWorker(ABC):    @abstractmethoddefwork(self):pass    @abstractmethoddefeat(self):pass    @abstractmethoddefsleep(self):passclassHumanWorker(Worker):defwork(self):return"工作"defeat(self):return"吃饭"defsleep(self):return"睡觉"classRobotWorker(Worker):defwork(self):return"工作"defeat(self):raise Exception("机器人不需要吃饭")  # ❌ 被迫实现不需要的方法defsleep(self):raise Exception("机器人不需要睡觉")  # ❌# 问题:RobotWorker 被迫实现了它不需要的方法

5.2 遵循原则的改进

from abc import ABC, abstractmethodclassWorkable(ABC):    @abstractmethoddefwork(self):passclassEatable(ABC):    @abstractmethoddefeat(self):passclassSleepable(ABC):    @abstractmethoddefsleep(self):passclassHumanWorker(Workable, Eatable, Sleepable):defwork(self):return"工作"defeat(self):return"吃饭"defsleep(self):return"睡觉"classRobotWorker(Workable):defwork(self):return"工作"# 不需要实现 eat() 和 sleep() ✅# 使用defstart_work(worker: Workable):print(worker.work())start_work(HumanWorker())start_work(RobotWorker())

六、D:依赖倒置原则

高层模块不应该依赖低层模块,两者都应该依赖抽象。抽象不应该依赖细节,细节应该依赖抽象。

6.1 违反原则的示例

classEmailSender:defsend(self, message):print(f"发送邮件: {message}")classNotificationService:def__init__(self):self.sender = EmailSender()  # ❌ 直接依赖具体实现defnotify(self, message):self.sender.send(message)# 问题:要改用短信发送时,需要修改 NotificationService 类

6.2 遵循原则的改进

from abc import ABC, abstractmethodclassMessageSender(ABC):"""抽象接口"""    @abstractmethoddefsend(self, message):passclassEmailSender(MessageSender):defsend(self, message):print(f"发送邮件: {message}")classSMSSender(MessageSender):defsend(self, message):print(f"发送短信: {message}")classWeChatSender(MessageSender):defsend(self, message):print(f"发送微信: {message}")classNotificationService:def__init__(self, sender: MessageSender):  # ✅ 依赖抽象,而非具体self.sender = senderdefnotify(self, message):self.sender.send(message)# 使用:可以轻松切换发送方式email_service = NotificationService(EmailSender())email_service.notify("Hello")sms_service = NotificationService(SMSSender())sms_service.notify("Hello")wechat_service = NotificationService(WeChatSender())wechat_service.notify("Hello")

七、综合案例:用户管理系统

from abc import ABC, abstractmethodfrom typing importList, Dict# ============ 单一职责:拆分职责 ============classUser:"""用户实体(只负责数据)"""def__init__(self, id: int, name: str, email: str, role: str):self.id = idself.name = nameself.email = emailself.role = role# ============ 依赖倒置和开闭原则 ============classUserRepository(ABC):"""用户存储抽象"""    @abstractmethoddefsave(self, user: User) -> User:pass    @abstractmethoddeffind_by_id(self, id: int) -> User:pass    @abstractmethoddeffind_all(self) -> List[User]:passclassInMemoryUserRepository(UserRepository):"""内存存储实现"""def__init__(self):self._users: Dict[int, User] = {}defsave(self, user: User) -> User:self._users[user.id] = userreturn userdeffind_by_id(self, id: int) -> User:returnself._users.get(id)deffind_all(self) -> List[User]:returnlist(self._users.values())# ============ 鉴权策略(开闭原则) ============classAuthorizationStrategy(ABC):"""权限验证抽象"""    @abstractmethoddefhas_permission(self, user: User, permission: str) -> bool:passclassAdminOnlyStrategy(AuthorizationStrategy):defhas_permission(self, user: User, permission: str) -> bool:return user.role == "admin"classRoleBasedStrategy(AuthorizationStrategy):    PERMISSIONS = {"admin": ["read", "write", "delete"],"user": ["read"],"editor": ["read", "write"]    }defhas_permission(self, user: User, permission: str) -> bool:        perms = self.PERMISSIONS.get(user.role, [])return permission in perms# ============ 用户服务(依赖抽象) ============classUserService:def__init__(self, repository: UserRepository, auth_strategy: AuthorizationStrategy):self.repository = repositoryself.auth_strategy = auth_strategydefdelete_user(self, current_user: User, user_id: int):ifnotself.auth_strategy.has_permission(current_user, "delete"):raise PermissionError("没有删除权限")        user = self.repository.find_by_id(user_id)if user:print(f"删除用户: {user.name}")else:print("用户不存在")# ============ 使用 ============# 创建用户admin = User(1, "管理员", "admin@example.com", "admin")editor = User(2, "编辑", "editor@example.com", "editor")user = User(3, "普通用户", "user@example.com", "user")# 创建存储repository = InMemoryUserRepository()repository.save(admin)repository.save(editor)repository.save(user)# 使用角色权限策略auth_strategy = RoleBasedStrategy()user_service = UserService(repository, auth_strategy)try:# 管理员可以删除    user_service.delete_user(admin, 2)# 普通用户尝试删除(应该失败)    user_service.delete_user(user, 1)except PermissionError as e:print(f"权限不足: {e}")

八、总结

原则
要点
实践方法
S
 单一职责
一个类只负责一件事
拆分大类、提取职责
O
 开闭原则
对扩展开放,对修改关闭
策略模式、依赖抽象
L
 里氏替换
子类必须能替换父类
不改变父类语义
I
 接口隔离
避免胖接口
拆分成多个专用接口
D
 依赖倒置
依赖抽象而非具体
依赖注入、面向接口编程

核心要点:

  • • SOLID 原则是指导代码设计的准则,而非必须严格遵守的教条。
  • • 在实际开发中,需要根据项目情况权衡应用。
  • • 遵循 SOLID 原则的代码通常更易于测试、维护和扩展。
  • • 原则之间相互关联,共同促进良好的代码设计。
  • • 持续重构是逐步接近 SOLID 原则的有效方式。

掌握 SOLID 原则,是写出高质量、可维护的面向对象代码的重要基础。

最新文章

随机文章