1. 这不是概念背诵题而是代码重构的实战指南很多人第一次接触“面向对象三大特性”和“设计原则”时以为只是面试前要默写的八股文——封装、继承、多态单一职责、开闭原则、里氏替换……背得滚瓜烂熟一写真实项目就全忘光。我见过某高校课程设计里一个叫UserManager的类里塞了数据库连接、密码加密、邮件发送、日志记录、Excel导出、前端模板渲染还带三个不同版本的登录校验逻辑。它确实“能跑”但当导师要求把邮箱服务换成钉钉通知时学生改了17个地方测试崩了9个用例最后回滚到三天前的版本重来。这不是能力问题是没真正理解这些术语不是贴在类图上的装饰标签而是你每天敲代码时手边的手术刀、止血钳和无影灯。它们解决的从来不是“要不要用面向对象”而是“当需求开始蠕动、模块开始纠缠、协作开始卡顿、上线前夜突然加急改需求时你怎么不让自己崩溃”。本文不讲定义复述不列教科书式条目只讲我在多个中型项目中反复验证过的实操逻辑为什么__init__里不该直接new一个数据库连接为什么“继承”在Python里常是第一个该被删掉的选项为什么“开闭原则”在真实业务中往往意味着“先闭后开”而不是反过来所有结论都来自真实调试现场——比如那个凌晨三点发现super().__init__()调用顺序错位导致配置丢失的线上事故比如为满足“里氏替换”硬生生重构掉2300行if-else后新增支付渠道只改了47行代码的轻松感。如果你正被“明明按教程写了类却越写越乱”困扰或者团队Code Review总在争论“这个类到底该不该拆”那这篇就是为你写的。2. 三大特性不是并列关系而是演进链条从数据容器到行为契约Python里的面向对象三大特性——封装、继承、多态——常被当作三个独立知识点平铺讲解。但实际开发中它们是一条清晰的演进路径封装是起点继承是过渡多态才是终点目标。忽略这个顺序就会陷入“为了继承而继承”的泥潭。2.1 封装不是藏起来而是划清责任边界初学者常把封装等同于“把属性改成__name”以为加了双下划线就安全了。这完全误解了封装的本质。Python的封装核心不是技术限制而是责任声明。看这个反例class Order: def __init__(self, items, user_id, total_price): self.items items # 列表可被外部任意修改 self.user_id user_id self.total_price total_price # 可被外部随意赋值 self.status pending这个类看似“有属性”实则毫无封装。外部代码可以随时执行order.items.append(fake_item)或order.total_price -100系统状态瞬间不可信。真正的封装是让类自己掌控状态变更的入口和规则class Order: def __init__(self, items, user_id, total_price): self._items [] # 私有存储 self._user_id user_id self._total_price 0.0 self._status pending # 通过受控方法初始化 self.add_items(items) self._calculate_total() # 立即计算不依赖外部调用 def add_items(self, new_items): 添加商品自动校验并更新总价 if not isinstance(new_items, list): raise TypeError(items must be a list) for item in new_items: if not hasattr(item, price) or not hasattr(item, name): raise ValueError(item must have price and name) self._items.extend(new_items) self._calculate_total() def _calculate_total(self): 私有方法确保总价永远与items一致 self._total_price sum(item.price for item in self._items) property def total_price(self): 只读属性外部无法直接修改 return round(self._total_price, 2) property def items(self): 返回不可变副本防止外部篡改 return tuple(self._items) # 返回tuple而非list这里的关键转变在于items不再是一个可被任意修改的列表而是一个只能通过add_items()方法变更的受控集合total_price不再是可写字段而是由_calculate_total()保证与items严格同步的只读结果所有状态变更都集中在少数几个明确命名的方法中每个方法都有清晰的契约输入校验、副作用说明。提示Python中property不是语法糖它是封装的基础设施。当你发现某个属性需要“读取时计算”“写入时校验”“删除时清理”property就是最自然的表达方式比一堆get_xxx()/set_xxx()方法更符合Python哲学。2.2 继承Python里最常被误用的特性继承在Java/C#中是构建类型体系的核心在Python中却常是第一个该被质疑的设计选择。原因很现实Python有更灵活的替代方案且继承链一旦形成修改成本极高。看一个典型误用场景某电商系统需要支持多种订单类型普通订单、团购订单、预售订单开发者第一反应是建一个基类BaseOrder再派生三个子类class BaseOrder: def __init__(self, user_id): self.user_id user_id self.created_at datetime.now() def calculate_discount(self): raise NotImplementedError def validate_payment(self): raise NotImplementedError class GroupOrder(BaseOrder): def __init__(self, user_id, group_id): super().__init__(user_id) self.group_id group_id def calculate_discount(self): return 0.15 # 团购打85折 def validate_payment(self): return self.group_id is not None class PreSaleOrder(BaseOrder): def __init__(self, user_id, deposit_amount): super().__init__(user_id) self.deposit_amount deposit_amount def calculate_discount(self): return 0.05 # 预售定金抵扣5% def validate_payment(self): return self.deposit_amount 0表面看结构清晰但问题立刻浮现新增“跨境订单”需改基类加shipping_country字段和所有子类某天产品要求“团购订单也可用定金”GroupOrder就得同时继承GroupOrder和PreSaleOrder而Python多重继承的MRO方法解析顺序会让super().__init__()调用变得极其脆弱单元测试必须为每个子类单独覆盖维护成本指数级增长。更Pythonic的解法是组合策略模式from abc import ABC, abstractmethod from typing import Protocol class DiscountStrategy(Protocol): def calculate(self, order: Order) - float: ... class FlatDiscount: def __init__(self, rate: float): self.rate rate def calculate(self, order: Order) - float: return self.rate class GroupDiscount: def calculate(self, order: Order) - float: return 0.15 if order.group_id else 0.0 class Order: def __init__(self, user_id: str, discount_strategy: DiscountStrategy): self.user_id user_id self.discount_strategy discount_strategy # 组合非继承 self.created_at datetime.now() def get_discount(self) - float: return self.discount_strategy.calculate(self) # 使用时动态注入策略 group_order Order(u123, GroupDiscount()) pre_sale_order Order(u456, FlatDiscount(0.05))这里的关键洞察是继承表达的是is-a是一个关系而组合表达的是has-a有一个关系。在业务系统中90%的所谓is-a其实是behaves-like-a行为像一个。GroupOrder不是一种特殊的Order而是Order在特定场景下应用了GroupDiscount策略。组合让变化点折扣规则与稳定点订单核心结构彻底解耦新增策略只需实现DiscountStrategy协议无需触碰Order类本身。2.3 多态不是运行时类型判断而是接口契约的统一调用多态常被简化为“父类引用指向子类对象”但在Python中由于鸭子类型Duck Typing的存在多态的实现更轻量、更本质——只要对象有相同的方法签名和行为契约就能被同一段代码处理。看一个反模式用isinstance()做类型判断来实现“多态”def process_payment(order): if isinstance(order, CreditCardOrder): return credit_card_charge(order.card_number, order.amount) elif isinstance(order, AlipayOrder): return alipay_pay(order.alipay_account, order.amount) elif isinstance(order, WechatOrder): return wechat_pay(order.wechat_id, order.amount) else: raise ValueError(Unsupported order type)这根本不是多态这是硬编码的分支逻辑每次新增支付方式都要改这个函数严重违反开闭原则。真正的多态是定义清晰的接口协议让所有支付方式都遵循它from typing import Protocol class PaymentProcessor(Protocol): def charge(self, amount: float) - str: # 返回交易ID ... class CreditCardProcessor: def __init__(self, card_number: str): self.card_number card_number def charge(self, amount: float) - str: # 实际调用银联接口 return fCC_{uuid4().hex[:8]} class AlipayProcessor: def __init__(self, account: str): self.account account def charge(self, amount: float) - str: # 实际调用支付宝SDK return fALI_{uuid4().hex[:8]} def process_payment(processor: PaymentProcessor, amount: float) - str: 函数只依赖PaymentProcessor协议不关心具体类型 return processor.charge(amount) # 调用方完全解耦 cc_processor CreditCardProcessor(4123****5678) alipay_processor AlipayProcessor(useralipay.com) print(process_payment(cc_processor, 100.0)) # CC_a1b2c3d4 print(process_payment(alipay_processor, 100.0)) # ALI_e5f6g7h8这里没有class PaymentProcessor(metaclassABCMeta)的繁重声明只有Protocol——Python 3.8的结构化类型检查工具。它告诉IDE和类型检查器“任何有charge方法的对象都可传给process_payment”。运行时零开销开发时强提示这才是Python多态的精髓。注意不要为了“看起来像Java”而滥用抽象基类ABC。当你的协议只有1-2个方法且所有实现都简单直接时Protocol比ABC更轻量、更Pythonic。ABC更适合需要强制子类实现某些方法或需要isinstance()运行时检查的极少数场景。3. 六大原则不是教条而是每次代码审查时的提问清单所谓“六大原则”SOLID DRY/KISS本质是六组经过千锤百炼的问题清单。每次你写完一个类、一个函数、一个模块都应该自问这些问题。它们不是用来打分的而是帮你提前嗅到代码腐化的气味。3.1 单一职责原则SRP一个类只负责一件事但“一件事”怎么定义SRP常被误解为“一个类只做一种操作”比如“User类只管用户数据不处理登录”。这太浅薄。真正的单一职责是“只有一个理由让这个类被修改”。看这个例子class ReportGenerator: def __init__(self, data_source): self.data_source data_source def generate_pdf(self): # 1. 从data_source获取数据 # 2. 渲染PDF模板 # 3. 写入文件系统 # 4. 发送邮件通知 pass def generate_excel(self): # 1. 从data_source获取数据 # 2. 渲染Excel模板 # 3. 写入文件系统 # 4. 发送邮件通知 pass这个类有四个修改理由PDF模板变了、Excel模板变了、文件存储路径变了、邮件内容变了。任何一个变化都可能影响其他功能。重构后职责被拆解为清晰的协作链class DataFetcher: 只负责获取数据 —— 修改理由数据源API变更 def fetch(self): return self.data_source.query() class PDFRenderer: 只负责渲染PDF —— 修改理由PDF样式/布局调整 def render(self, data): return pdfkit.from_string(template.render(data), False) class FileStorage: 只负责存文件 —— 修改理由存储位置/权限变更 def save(self, content, filename): with open(f/reports/{filename}, wb) as f: f.write(content) class EmailNotifier: 只负责发邮件 —— 修改理由邮件模板/收件人规则变更 def notify(self, report_id): send_mail(toadmincompany.com, subjectfReport {report_id} ready) # 协作流程 def generate_report(report_type: str): data DataFetcher(db).fetch() if report_type pdf: content PDFRenderer().render(data) else: content ExcelRenderer().render(data) filename freport_{uuid4().hex}.pdf FileStorage().save(content, filename) EmailNotifier().notify(filename)现在每个类只有一个修改理由。更重要的是当产品说“报告生成后要同时存到S3和本地磁盘”时你只需新增一个S3Storage类并在generate_report中调用它完全不碰FileStorage或PDFRenderer。这就是SRP带来的可扩展性。3.2 开闭原则OCP对扩展开放对修改关闭——但“扩展”必须有边界OCP常被曲解为“永远不能改代码”这不可能。它的真意是当新需求到来时应通过添加新代码新类、新函数来满足而非修改现有稳定代码。关键在于识别“什么该稳定什么该开放”。以日志系统为例。最初需求很简单def log_message(message): with open(/var/log/app.log, a) as f: f.write(f[{datetime.now()}] {message}\n)后来要支持控制台输出、数据库记录、远程HTTP上报。如果按传统思路每次加一种日志方式就改log_message函数很快它会变成这样def log_message(message, output_typefile): if output_type file: # ... file logic elif output_type console: # ... console logic elif output_type db: # ... db logic elif output_type http: # ... http logic # ... 新增类型继续加elif这明显违反OCP——每次加新类型都要改这个函数。正确做法是定义日志处理器协议并让log_message依赖它from typing import Protocol class LogHandler(Protocol): def handle(self, message: str) - None: ... class FileLogHandler: def __init__(self, path: str): self.path path def handle(self, message: str) - None: with open(self.path, a) as f: f.write(f[{datetime.now()}] {message}\n) class ConsoleLogHandler: def handle(self, message: str) - None: print(f[{datetime.now()}] {message}) class CompositeLogHandler: 组合多个处理器实现“同时输出到多处” def __init__(self, handlers: list[LogHandler]): self.handlers handlers def handle(self, message: str) - None: for h in self.handlers: h.handle(message) # 全局日志器只依赖协议 _logger CompositeLogHandler([ FileLogHandler(/var/log/app.log), ConsoleLogHandler() ]) def log_message(message: str) - None: _logger.handle(message) # 新增HTTP上报只需写新类不改任何现有代码 class HttpLogHandler: def __init__(self, endpoint: str): self.endpoint endpoint def handle(self, message: str) - None: requests.post(self.endpoint, json{msg: message}) # 启用HTTP上报只改初始化不改log_message函数 _logger CompositeLogHandler([ FileLogHandler(/var/log/app.log), ConsoleLogHandler(), HttpLogHandler(https://api.logs.com) ])这里的关键设计决策是将“日志输出方式”这个变化点封装在LogHandler协议中将“日志消息格式化”这个稳定点保留在log_message函数内。OCP不是禁止修改而是把修改引导到最安全的地方——新类的创建而非旧函数的修补。3.3 里氏替换原则LSP子类必须能无缝替换父类——但Python里常靠协议代替继承LSP的核心是任何使用父类对象的地方都能用子类对象替换且程序行为不变。在静态类型语言中这常通过继承强制约束在Python中我们更倾向用协议Protocol和鸭子类型来实现因为更灵活、更少陷阱。看一个经典的LSP违规案例——Rectangle和Squareclass Rectangle: def __init__(self, width: float, height: float): self._width width self._height height property def width(self) - float: return self._width width.setter def width(self, value: float): self._width value property def height(self) - float: return self._height height.setter def height(self, value: float): self._height value def area(self) - float: return self._width * self._height class Square(Rectangle): # 违反LSP def __init__(self, side: float): super().__init__(side, side) property def width(self) - float: return self._width width.setter def width(self, value: float): self._width self._height value # 同时改width和height property def height(self) - float: return self._height height.setter def height(self, value: float): self._width self._height value # 同时改width和height问题在于Rectangle的使用者假设width和height是独立可变的。但Square的setter强制两者相等导致以下代码行为异常def resize_to_square(rect: Rectangle): rect.width 10 rect.height 10 assert rect.width rect.height # 在Rectangle上成立在Square上也成立 # 但下面这行会出问题 rect.width 5 # 在Square中height也被设为5 assert rect.area() 5 * 10 # 期望50实际得到25Square不能安全替换Rectangle因为它破坏了Rectangle的隐含契约宽高可独立设置。Python的解决方案不是修复继承而是放弃继承用协议定义行为契约from typing import Protocol class Shape(Protocol): def area(self) - float: ... class Rectangle: def __init__(self, width: float, height: float): self.width width self.height height def area(self) - float: return self.width * self.height class Square: def __init__(self, side: float): self.side side def area(self) - float: return self.side ** 2 # 函数只依赖Shape协议不关心是Rectangle还是Square def print_area(shape: Shape) - None: print(fArea: {shape.area()}) print_area(Rectangle(5, 10)) # Area: 50 print_area(Square(7)) # Area: 49这里Rectangle和Square没有继承关系但都实现了Shape协议因此都能被print_area安全调用。LSP的约束被转移到了协议层面——只要实现了area()方法就满足契约。这比继承更健壮因为协议只承诺你需要的行为不承诺你不想要的约束如宽高独立性。3.4 接口隔离原则ISP客户端不应依赖它不需要的接口ISP直指一个常见痛点一个庞大的接口如一个包含20个方法的基类迫使所有实现者都必须提供所有方法的空实现哪怕90%的方法对它毫无意义。这在Python中常表现为“上帝类”或过度设计的抽象基类。反例一个NotificationService基类试图统一所有通知渠道from abc import ABC, abstractmethod class NotificationService(ABC): abstractmethod def send_sms(self, phone: str, message: str) - str: ... abstractmethod def send_email(self, to: str, subject: str, body: str) - str: ... abstractmethod def send_push(self, device_token: str, title: str, content: str) - str: ... abstractmethod def send_webhook(self, url: str, payload: dict) - str: ... abstractmethod def send_slack(self, channel: str, text: str) - str: ... # ... 还有15个其他方法现在要实现一个只发邮件的服务class EmailOnlyService(NotificationService): def send_sms(self, phone, message): raise NotImplementedError(Not supported) def send_email(self, to, subject, body): return send_smtp(to, subject, body) def send_push(self, token, title, content): raise NotImplementedError(Not supported) def send_webhook(self, url, payload): raise NotImplementedError(Not supported) def send_slack(self, channel, text): raise NotImplementedError(Not supported) # ... 还要实现另外15个raise NotImplementedError这违背了ISP——EmailOnlyService被迫依赖并实现它完全不需要的19个方法。正确做法是拆分为小而专的协议from typing import Protocol class EmailSender(Protocol): def send(self, to: str, subject: str, body: str) - str: ... class SMSSender(Protocol): def send(self, phone: str, message: str) - str: ... class PushSender(Protocol): def send(self, token: str, title: str, content: str) - str: ... # 具体实现只实现所需协议 class SMTPService: def send(self, to: str, subject: str, body: str) - str: return send_smtp(to, subject, body) class TwilioService: def send(self, phone: str, message: str) - str: return twilio_send(phone, message) # 使用方按需依赖 def notify_user(email_service: EmailSender, sms_service: SMSSender, user: User): email_service.send(user.email, Welcome, Hello!) if user.phone: sms_service.send(user.phone, Welcome SMS)现在SMTPService只实现EmailSenderTwilioService只实现SMSSender各司其职互不干扰。当系统只需要邮件通知时就只注入SMTPService完全不感知短信服务的存在。接口被隔离了依赖被精简了代码也清爽了。3.5 依赖倒置原则DIP高层模块不应依赖低层模块二者都应依赖抽象DIP常被简化为“面向接口编程”但它更深层的含义是抽象协议/接口不应依赖于细节具体实现细节应依赖于抽象。这解决了模块间的硬耦合问题。看一个典型的紧耦合案例class PaymentProcessor: def __init__(self): self.db DatabaseConnection() # 直接依赖具体类 self.logger FileLogger() # 直接依赖具体类 def process(self, order): try: self.db.save_order(order) # 直接调用DB方法 self.logger.log(fOrder {order.id} processed) # 直接调用Logger方法 return True except Exception as e: self.logger.log(fError processing {order.id}: {e}) return False这个类同时依赖DatabaseConnection和FileLogger两个具体实现。问题来了测试时无法Mock数据库和日志只能走真实IO测试慢且不稳定想把日志换成数据库存储必须改PaymentProcessor源码想用内存数据库做单元测试同样要改源码。DIP的解法是让PaymentProcessor只依赖抽象协议具体实现由外部注入from typing import Protocol class Database(Protocol): def save_order(self, order) - None: ... class Logger(Protocol): def log(self, message: str) - None: ... class PaymentProcessor: def __init__(self, db: Database, logger: Logger): self.db db # 依赖抽象 self.logger logger # 依赖抽象 def process(self, order): try: self.db.save_order(order) # 调用抽象方法 self.logger.log(fOrder {order.id} processed) return True except Exception as e: self.logger.log(fError processing {order.id}: {e}) return False # 具体实现 class MySQLDatabase: def save_order(self, order): # 实际MySQL操作 pass class CloudWatchLogger: def log(self, message): # 实际CloudWatch调用 pass # 组装依赖注入 processor PaymentProcessor( dbMySQLDatabase(), loggerCloudWatchLogger() )现在PaymentProcessor完全不知道MySQL或CloudWatch的存在它只认识Database和Logger这两个协议。测试时可以轻松注入Mockclass MockDatabase: def __init__(self): self.saved_orders [] def save_order(self, order): self.saved_orders.append(order) class MockLogger: def __init__(self): self.logs [] def log(self, message): self.logs.append(message) # 测试 mock_db MockDatabase() mock_logger MockLogger() processor PaymentProcessor(mock_db, mock_logger) processor.process(test_order) assert len(mock_db.saved_orders) 1 assert processed in mock_logger.logs[0]DIP让PaymentProcessor成为可测试、可替换、可组合的乐高积木而不是焊死在混凝土里的钢筋。3.6 迪米特法则LoD与KISS只和“朋友”说话保持简单迪米特法则Law of Demeter常被记作“最少知道原则”一个对象应该对其他对象有最少的了解。通俗说不要链式调用a.b.c.d.method()而应让a提供a.doSomething()方法。KISSKeep It Simple, Stupid则是对复杂度的终极警告。看一个违反LoD的典型链式调用# 用户下单后要获取其所在城市的GDP排名 gdp_rank user.profile.address.city.economic_data.gdp_rank这里user对象层层深入暴露了profile、address、city、economic_data四个中间对象的内部结构。问题在于一旦address类重构比如把city改为location这行代码立即报错user类本不该知道economic_data的存在它只该关心“我的城市GDP排名是多少”这个业务问题。LoD的解决方案是“封装导航”让对象自己回答问题class User: def __init__(self, profile): self.profile profile def get_city_gdp_rank(self) - int: User自己封装了如何获取GDP排名的路径 if not self.profile or not self.profile.address or not self.profile.address.city: return 0 return self.profile.address.city.get_gdp_rank() # 委托给city class City: def __init__(self, economic_data): self.economic_data economic_data def get_gdp_rank(self) - int: return self.economic_data.gdp_rank # 调用方现在只需 gdp_rank user.get_city_gdp_rank() # 简单、稳定、语义清晰User类承担了导航的责任对外隐藏了内部结构。即使未来City的economic_data被合并到City自身只需改City.get_gdp_rank()的实现User.get_city_gdp_rank()和所有调用方代码完全不受影响。KISS原则则提醒我们当一个设计开始需要画UML图、写10页文档才能让人看懂时它大概率已经过载了。比如为支持“未来可能的多租户”而提前在所有模型上加tenant_id字段或为“理论上需要的扩展性”而引入五层抽象工厂。真实项目中80%的“未来需求”永远不会来而100%的过度设计都会增加当前的维护成本。我的经验是先用最直接的方式实现当前需求当同一个模式重复出现3次以上时再提取抽象。比如当第3个API客户端都需要处理token刷新、重试、超时才去写BaseAPIClient当第3个数据类都需要JSON序列化/反序列化才去写SerializableMixin。简单不是偷懒而是对复杂度的敬畏。4. 从理论到落地一个真实订单系统的渐进式重构纸上谈兵终觉浅。下面用一个真实的中型电商订单系统重构案例展示如何将三大特性和六大原则串联起来解决实际问题。这个系统最初由实习生快速搭建核心是Order类约1200行包含订单管理、库存扣减、物流跟踪、发票生成、风控校验、优惠券计算、积分发放、短信通知等全部逻辑。上线三个月后每次加一个新功能如“企业客户专属运费险”平均要改87行代码平均引发3.2个回归Bug。4.1 第一阶段识别腐化信号划定重构边界重构不是重写而是有策略的渐进式改进。第一步是诊断哪些代码最痛我们用三个指标筛选指标计算方式高风险阈值本系统TOP3修改频率过去30天Git提交次数≥5次Order.calculate_final_price()(12次)圈复杂度radon cc分析≥15Order.process_payment()(23)测试覆盖率pytest --cov≤30%Order.generate_invoice()(8%)聚焦calculate_final_price()——它负责整合优惠券、满减、会员折扣、跨店满减、限时折扣等7种规则用嵌套if-else和全局状态变量实现。每次产品调整“满300减50”的门槛都要在这里改逻辑且极易影响其他折扣。重构目标明确将价格计算逻辑剥离使其可独立测试、可配置、可替换。这直接对应SRP单一职责、OCP新增折扣类型不改现有代码、DIP价格计算器依赖抽象协议。4.2 第二阶段定义协议实现策略注入依赖首先定义价格计算的抽象协议from typing import Protocol, List, Optional from dataclasses import dataclass dataclass class Discount: name: str amount: float description: str class PriceCalculator(Protocol): def calculate(self, base_price: float, order_items: List[Item], user: User) - tuple[float, List[Discount]]: 返回最终价格和应用的折扣列表 ...然后为每种折扣规则实现具体策略class CouponDiscount: def __init__(self, coupon_code: str, discount_amount: float): self.coupon_code coupon_code self.discount_amount discount_amount def calculate(self, base_price: float, order_items: List[Item], user: User) - tuple[float, List[Discount]]: if user.has_valid_coupon(self.coupon_code): final max(0, base_price - self.discount_amount) return final, [Discount(Coupon, self.discount_amount, fUse {self.coupon_code})] return base_price, [] class MemberDiscount: def __init__(self, member_tier: str, rate: float): self.member_tier member_tier self.rate rate def calculate(self, base_price: float, order_items: List[Item], user: User) - tuple[float, List[Discount]]: if user.tier self.member_tier: discount base_price * self.rate return base_price - discount, [Discount(Member, discount, f{self.member_tier} discount)] return base_price, []关键一步修改Order类移除原有计算逻辑注入PriceCalculatorclass Order: def __init__(self, items: List[Item], user: User, price_calculator: PriceCalculator): self.items items self.user user self._price_calculator price_calculator # 依赖倒置 self._base_price sum(item.price * item.quantity for item in items) property def final_price(self) - float: 单一职责只负责委托计算不参与逻辑 final, _ self._price_calculator.calculate( self._base_price, self.items, self.user ) return final
1. 这不是概念背诵题而是代码重构的实战指南很多人第一次接触“面向对象三大特性”和“设计原则”时以为只是面试前要默写的八股文——封装、继承、多态单一职责、开闭原则、里氏替换……背得滚瓜烂熟一写真实项目就全忘光。我见过某高校课程设计里一个叫UserManager的类里塞了数据库连接、密码加密、邮件发送、日志记录、Excel导出、前端模板渲染还带三个不同版本的登录校验逻辑。它确实“能跑”但当导师要求把邮箱服务换成钉钉通知时学生改了17个地方测试崩了9个用例最后回滚到三天前的版本重来。这不是能力问题是没真正理解这些术语不是贴在类图上的装饰标签而是你每天敲代码时手边的手术刀、止血钳和无影灯。它们解决的从来不是“要不要用面向对象”而是“当需求开始蠕动、模块开始纠缠、协作开始卡顿、上线前夜突然加急改需求时你怎么不让自己崩溃”。本文不讲定义复述不列教科书式条目只讲我在多个中型项目中反复验证过的实操逻辑为什么__init__里不该直接new一个数据库连接为什么“继承”在Python里常是第一个该被删掉的选项为什么“开闭原则”在真实业务中往往意味着“先闭后开”而不是反过来所有结论都来自真实调试现场——比如那个凌晨三点发现super().__init__()调用顺序错位导致配置丢失的线上事故比如为满足“里氏替换”硬生生重构掉2300行if-else后新增支付渠道只改了47行代码的轻松感。如果你正被“明明按教程写了类却越写越乱”困扰或者团队Code Review总在争论“这个类到底该不该拆”那这篇就是为你写的。2. 三大特性不是并列关系而是演进链条从数据容器到行为契约Python里的面向对象三大特性——封装、继承、多态——常被当作三个独立知识点平铺讲解。但实际开发中它们是一条清晰的演进路径封装是起点继承是过渡多态才是终点目标。忽略这个顺序就会陷入“为了继承而继承”的泥潭。2.1 封装不是藏起来而是划清责任边界初学者常把封装等同于“把属性改成__name”以为加了双下划线就安全了。这完全误解了封装的本质。Python的封装核心不是技术限制而是责任声明。看这个反例class Order: def __init__(self, items, user_id, total_price): self.items items # 列表可被外部任意修改 self.user_id user_id self.total_price total_price # 可被外部随意赋值 self.status pending这个类看似“有属性”实则毫无封装。外部代码可以随时执行order.items.append(fake_item)或order.total_price -100系统状态瞬间不可信。真正的封装是让类自己掌控状态变更的入口和规则class Order: def __init__(self, items, user_id, total_price): self._items [] # 私有存储 self._user_id user_id self._total_price 0.0 self._status pending # 通过受控方法初始化 self.add_items(items) self._calculate_total() # 立即计算不依赖外部调用 def add_items(self, new_items): 添加商品自动校验并更新总价 if not isinstance(new_items, list): raise TypeError(items must be a list) for item in new_items: if not hasattr(item, price) or not hasattr(item, name): raise ValueError(item must have price and name) self._items.extend(new_items) self._calculate_total() def _calculate_total(self): 私有方法确保总价永远与items一致 self._total_price sum(item.price for item in self._items) property def total_price(self): 只读属性外部无法直接修改 return round(self._total_price, 2) property def items(self): 返回不可变副本防止外部篡改 return tuple(self._items) # 返回tuple而非list这里的关键转变在于items不再是一个可被任意修改的列表而是一个只能通过add_items()方法变更的受控集合total_price不再是可写字段而是由_calculate_total()保证与items严格同步的只读结果所有状态变更都集中在少数几个明确命名的方法中每个方法都有清晰的契约输入校验、副作用说明。提示Python中property不是语法糖它是封装的基础设施。当你发现某个属性需要“读取时计算”“写入时校验”“删除时清理”property就是最自然的表达方式比一堆get_xxx()/set_xxx()方法更符合Python哲学。2.2 继承Python里最常被误用的特性继承在Java/C#中是构建类型体系的核心在Python中却常是第一个该被质疑的设计选择。原因很现实Python有更灵活的替代方案且继承链一旦形成修改成本极高。看一个典型误用场景某电商系统需要支持多种订单类型普通订单、团购订单、预售订单开发者第一反应是建一个基类BaseOrder再派生三个子类class BaseOrder: def __init__(self, user_id): self.user_id user_id self.created_at datetime.now() def calculate_discount(self): raise NotImplementedError def validate_payment(self): raise NotImplementedError class GroupOrder(BaseOrder): def __init__(self, user_id, group_id): super().__init__(user_id) self.group_id group_id def calculate_discount(self): return 0.15 # 团购打85折 def validate_payment(self): return self.group_id is not None class PreSaleOrder(BaseOrder): def __init__(self, user_id, deposit_amount): super().__init__(user_id) self.deposit_amount deposit_amount def calculate_discount(self): return 0.05 # 预售定金抵扣5% def validate_payment(self): return self.deposit_amount 0表面看结构清晰但问题立刻浮现新增“跨境订单”需改基类加shipping_country字段和所有子类某天产品要求“团购订单也可用定金”GroupOrder就得同时继承GroupOrder和PreSaleOrder而Python多重继承的MRO方法解析顺序会让super().__init__()调用变得极其脆弱单元测试必须为每个子类单独覆盖维护成本指数级增长。更Pythonic的解法是组合策略模式from abc import ABC, abstractmethod from typing import Protocol class DiscountStrategy(Protocol): def calculate(self, order: Order) - float: ... class FlatDiscount: def __init__(self, rate: float): self.rate rate def calculate(self, order: Order) - float: return self.rate class GroupDiscount: def calculate(self, order: Order) - float: return 0.15 if order.group_id else 0.0 class Order: def __init__(self, user_id: str, discount_strategy: DiscountStrategy): self.user_id user_id self.discount_strategy discount_strategy # 组合非继承 self.created_at datetime.now() def get_discount(self) - float: return self.discount_strategy.calculate(self) # 使用时动态注入策略 group_order Order(u123, GroupDiscount()) pre_sale_order Order(u456, FlatDiscount(0.05))这里的关键洞察是继承表达的是is-a是一个关系而组合表达的是has-a有一个关系。在业务系统中90%的所谓is-a其实是behaves-like-a行为像一个。GroupOrder不是一种特殊的Order而是Order在特定场景下应用了GroupDiscount策略。组合让变化点折扣规则与稳定点订单核心结构彻底解耦新增策略只需实现DiscountStrategy协议无需触碰Order类本身。2.3 多态不是运行时类型判断而是接口契约的统一调用多态常被简化为“父类引用指向子类对象”但在Python中由于鸭子类型Duck Typing的存在多态的实现更轻量、更本质——只要对象有相同的方法签名和行为契约就能被同一段代码处理。看一个反模式用isinstance()做类型判断来实现“多态”def process_payment(order): if isinstance(order, CreditCardOrder): return credit_card_charge(order.card_number, order.amount) elif isinstance(order, AlipayOrder): return alipay_pay(order.alipay_account, order.amount) elif isinstance(order, WechatOrder): return wechat_pay(order.wechat_id, order.amount) else: raise ValueError(Unsupported order type)这根本不是多态这是硬编码的分支逻辑每次新增支付方式都要改这个函数严重违反开闭原则。真正的多态是定义清晰的接口协议让所有支付方式都遵循它from typing import Protocol class PaymentProcessor(Protocol): def charge(self, amount: float) - str: # 返回交易ID ... class CreditCardProcessor: def __init__(self, card_number: str): self.card_number card_number def charge(self, amount: float) - str: # 实际调用银联接口 return fCC_{uuid4().hex[:8]} class AlipayProcessor: def __init__(self, account: str): self.account account def charge(self, amount: float) - str: # 实际调用支付宝SDK return fALI_{uuid4().hex[:8]} def process_payment(processor: PaymentProcessor, amount: float) - str: 函数只依赖PaymentProcessor协议不关心具体类型 return processor.charge(amount) # 调用方完全解耦 cc_processor CreditCardProcessor(4123****5678) alipay_processor AlipayProcessor(useralipay.com) print(process_payment(cc_processor, 100.0)) # CC_a1b2c3d4 print(process_payment(alipay_processor, 100.0)) # ALI_e5f6g7h8这里没有class PaymentProcessor(metaclassABCMeta)的繁重声明只有Protocol——Python 3.8的结构化类型检查工具。它告诉IDE和类型检查器“任何有charge方法的对象都可传给process_payment”。运行时零开销开发时强提示这才是Python多态的精髓。注意不要为了“看起来像Java”而滥用抽象基类ABC。当你的协议只有1-2个方法且所有实现都简单直接时Protocol比ABC更轻量、更Pythonic。ABC更适合需要强制子类实现某些方法或需要isinstance()运行时检查的极少数场景。3. 六大原则不是教条而是每次代码审查时的提问清单所谓“六大原则”SOLID DRY/KISS本质是六组经过千锤百炼的问题清单。每次你写完一个类、一个函数、一个模块都应该自问这些问题。它们不是用来打分的而是帮你提前嗅到代码腐化的气味。3.1 单一职责原则SRP一个类只负责一件事但“一件事”怎么定义SRP常被误解为“一个类只做一种操作”比如“User类只管用户数据不处理登录”。这太浅薄。真正的单一职责是“只有一个理由让这个类被修改”。看这个例子class ReportGenerator: def __init__(self, data_source): self.data_source data_source def generate_pdf(self): # 1. 从data_source获取数据 # 2. 渲染PDF模板 # 3. 写入文件系统 # 4. 发送邮件通知 pass def generate_excel(self): # 1. 从data_source获取数据 # 2. 渲染Excel模板 # 3. 写入文件系统 # 4. 发送邮件通知 pass这个类有四个修改理由PDF模板变了、Excel模板变了、文件存储路径变了、邮件内容变了。任何一个变化都可能影响其他功能。重构后职责被拆解为清晰的协作链class DataFetcher: 只负责获取数据 —— 修改理由数据源API变更 def fetch(self): return self.data_source.query() class PDFRenderer: 只负责渲染PDF —— 修改理由PDF样式/布局调整 def render(self, data): return pdfkit.from_string(template.render(data), False) class FileStorage: 只负责存文件 —— 修改理由存储位置/权限变更 def save(self, content, filename): with open(f/reports/{filename}, wb) as f: f.write(content) class EmailNotifier: 只负责发邮件 —— 修改理由邮件模板/收件人规则变更 def notify(self, report_id): send_mail(toadmincompany.com, subjectfReport {report_id} ready) # 协作流程 def generate_report(report_type: str): data DataFetcher(db).fetch() if report_type pdf: content PDFRenderer().render(data) else: content ExcelRenderer().render(data) filename freport_{uuid4().hex}.pdf FileStorage().save(content, filename) EmailNotifier().notify(filename)现在每个类只有一个修改理由。更重要的是当产品说“报告生成后要同时存到S3和本地磁盘”时你只需新增一个S3Storage类并在generate_report中调用它完全不碰FileStorage或PDFRenderer。这就是SRP带来的可扩展性。3.2 开闭原则OCP对扩展开放对修改关闭——但“扩展”必须有边界OCP常被曲解为“永远不能改代码”这不可能。它的真意是当新需求到来时应通过添加新代码新类、新函数来满足而非修改现有稳定代码。关键在于识别“什么该稳定什么该开放”。以日志系统为例。最初需求很简单def log_message(message): with open(/var/log/app.log, a) as f: f.write(f[{datetime.now()}] {message}\n)后来要支持控制台输出、数据库记录、远程HTTP上报。如果按传统思路每次加一种日志方式就改log_message函数很快它会变成这样def log_message(message, output_typefile): if output_type file: # ... file logic elif output_type console: # ... console logic elif output_type db: # ... db logic elif output_type http: # ... http logic # ... 新增类型继续加elif这明显违反OCP——每次加新类型都要改这个函数。正确做法是定义日志处理器协议并让log_message依赖它from typing import Protocol class LogHandler(Protocol): def handle(self, message: str) - None: ... class FileLogHandler: def __init__(self, path: str): self.path path def handle(self, message: str) - None: with open(self.path, a) as f: f.write(f[{datetime.now()}] {message}\n) class ConsoleLogHandler: def handle(self, message: str) - None: print(f[{datetime.now()}] {message}) class CompositeLogHandler: 组合多个处理器实现“同时输出到多处” def __init__(self, handlers: list[LogHandler]): self.handlers handlers def handle(self, message: str) - None: for h in self.handlers: h.handle(message) # 全局日志器只依赖协议 _logger CompositeLogHandler([ FileLogHandler(/var/log/app.log), ConsoleLogHandler() ]) def log_message(message: str) - None: _logger.handle(message) # 新增HTTP上报只需写新类不改任何现有代码 class HttpLogHandler: def __init__(self, endpoint: str): self.endpoint endpoint def handle(self, message: str) - None: requests.post(self.endpoint, json{msg: message}) # 启用HTTP上报只改初始化不改log_message函数 _logger CompositeLogHandler([ FileLogHandler(/var/log/app.log), ConsoleLogHandler(), HttpLogHandler(https://api.logs.com) ])这里的关键设计决策是将“日志输出方式”这个变化点封装在LogHandler协议中将“日志消息格式化”这个稳定点保留在log_message函数内。OCP不是禁止修改而是把修改引导到最安全的地方——新类的创建而非旧函数的修补。3.3 里氏替换原则LSP子类必须能无缝替换父类——但Python里常靠协议代替继承LSP的核心是任何使用父类对象的地方都能用子类对象替换且程序行为不变。在静态类型语言中这常通过继承强制约束在Python中我们更倾向用协议Protocol和鸭子类型来实现因为更灵活、更少陷阱。看一个经典的LSP违规案例——Rectangle和Squareclass Rectangle: def __init__(self, width: float, height: float): self._width width self._height height property def width(self) - float: return self._width width.setter def width(self, value: float): self._width value property def height(self) - float: return self._height height.setter def height(self, value: float): self._height value def area(self) - float: return self._width * self._height class Square(Rectangle): # 违反LSP def __init__(self, side: float): super().__init__(side, side) property def width(self) - float: return self._width width.setter def width(self, value: float): self._width self._height value # 同时改width和height property def height(self) - float: return self._height height.setter def height(self, value: float): self._width self._height value # 同时改width和height问题在于Rectangle的使用者假设width和height是独立可变的。但Square的setter强制两者相等导致以下代码行为异常def resize_to_square(rect: Rectangle): rect.width 10 rect.height 10 assert rect.width rect.height # 在Rectangle上成立在Square上也成立 # 但下面这行会出问题 rect.width 5 # 在Square中height也被设为5 assert rect.area() 5 * 10 # 期望50实际得到25Square不能安全替换Rectangle因为它破坏了Rectangle的隐含契约宽高可独立设置。Python的解决方案不是修复继承而是放弃继承用协议定义行为契约from typing import Protocol class Shape(Protocol): def area(self) - float: ... class Rectangle: def __init__(self, width: float, height: float): self.width width self.height height def area(self) - float: return self.width * self.height class Square: def __init__(self, side: float): self.side side def area(self) - float: return self.side ** 2 # 函数只依赖Shape协议不关心是Rectangle还是Square def print_area(shape: Shape) - None: print(fArea: {shape.area()}) print_area(Rectangle(5, 10)) # Area: 50 print_area(Square(7)) # Area: 49这里Rectangle和Square没有继承关系但都实现了Shape协议因此都能被print_area安全调用。LSP的约束被转移到了协议层面——只要实现了area()方法就满足契约。这比继承更健壮因为协议只承诺你需要的行为不承诺你不想要的约束如宽高独立性。3.4 接口隔离原则ISP客户端不应依赖它不需要的接口ISP直指一个常见痛点一个庞大的接口如一个包含20个方法的基类迫使所有实现者都必须提供所有方法的空实现哪怕90%的方法对它毫无意义。这在Python中常表现为“上帝类”或过度设计的抽象基类。反例一个NotificationService基类试图统一所有通知渠道from abc import ABC, abstractmethod class NotificationService(ABC): abstractmethod def send_sms(self, phone: str, message: str) - str: ... abstractmethod def send_email(self, to: str, subject: str, body: str) - str: ... abstractmethod def send_push(self, device_token: str, title: str, content: str) - str: ... abstractmethod def send_webhook(self, url: str, payload: dict) - str: ... abstractmethod def send_slack(self, channel: str, text: str) - str: ... # ... 还有15个其他方法现在要实现一个只发邮件的服务class EmailOnlyService(NotificationService): def send_sms(self, phone, message): raise NotImplementedError(Not supported) def send_email(self, to, subject, body): return send_smtp(to, subject, body) def send_push(self, token, title, content): raise NotImplementedError(Not supported) def send_webhook(self, url, payload): raise NotImplementedError(Not supported) def send_slack(self, channel, text): raise NotImplementedError(Not supported) # ... 还要实现另外15个raise NotImplementedError这违背了ISP——EmailOnlyService被迫依赖并实现它完全不需要的19个方法。正确做法是拆分为小而专的协议from typing import Protocol class EmailSender(Protocol): def send(self, to: str, subject: str, body: str) - str: ... class SMSSender(Protocol): def send(self, phone: str, message: str) - str: ... class PushSender(Protocol): def send(self, token: str, title: str, content: str) - str: ... # 具体实现只实现所需协议 class SMTPService: def send(self, to: str, subject: str, body: str) - str: return send_smtp(to, subject, body) class TwilioService: def send(self, phone: str, message: str) - str: return twilio_send(phone, message) # 使用方按需依赖 def notify_user(email_service: EmailSender, sms_service: SMSSender, user: User): email_service.send(user.email, Welcome, Hello!) if user.phone: sms_service.send(user.phone, Welcome SMS)现在SMTPService只实现EmailSenderTwilioService只实现SMSSender各司其职互不干扰。当系统只需要邮件通知时就只注入SMTPService完全不感知短信服务的存在。接口被隔离了依赖被精简了代码也清爽了。3.5 依赖倒置原则DIP高层模块不应依赖低层模块二者都应依赖抽象DIP常被简化为“面向接口编程”但它更深层的含义是抽象协议/接口不应依赖于细节具体实现细节应依赖于抽象。这解决了模块间的硬耦合问题。看一个典型的紧耦合案例class PaymentProcessor: def __init__(self): self.db DatabaseConnection() # 直接依赖具体类 self.logger FileLogger() # 直接依赖具体类 def process(self, order): try: self.db.save_order(order) # 直接调用DB方法 self.logger.log(fOrder {order.id} processed) # 直接调用Logger方法 return True except Exception as e: self.logger.log(fError processing {order.id}: {e}) return False这个类同时依赖DatabaseConnection和FileLogger两个具体实现。问题来了测试时无法Mock数据库和日志只能走真实IO测试慢且不稳定想把日志换成数据库存储必须改PaymentProcessor源码想用内存数据库做单元测试同样要改源码。DIP的解法是让PaymentProcessor只依赖抽象协议具体实现由外部注入from typing import Protocol class Database(Protocol): def save_order(self, order) - None: ... class Logger(Protocol): def log(self, message: str) - None: ... class PaymentProcessor: def __init__(self, db: Database, logger: Logger): self.db db # 依赖抽象 self.logger logger # 依赖抽象 def process(self, order): try: self.db.save_order(order) # 调用抽象方法 self.logger.log(fOrder {order.id} processed) return True except Exception as e: self.logger.log(fError processing {order.id}: {e}) return False # 具体实现 class MySQLDatabase: def save_order(self, order): # 实际MySQL操作 pass class CloudWatchLogger: def log(self, message): # 实际CloudWatch调用 pass # 组装依赖注入 processor PaymentProcessor( dbMySQLDatabase(), loggerCloudWatchLogger() )现在PaymentProcessor完全不知道MySQL或CloudWatch的存在它只认识Database和Logger这两个协议。测试时可以轻松注入Mockclass MockDatabase: def __init__(self): self.saved_orders [] def save_order(self, order): self.saved_orders.append(order) class MockLogger: def __init__(self): self.logs [] def log(self, message): self.logs.append(message) # 测试 mock_db MockDatabase() mock_logger MockLogger() processor PaymentProcessor(mock_db, mock_logger) processor.process(test_order) assert len(mock_db.saved_orders) 1 assert processed in mock_logger.logs[0]DIP让PaymentProcessor成为可测试、可替换、可组合的乐高积木而不是焊死在混凝土里的钢筋。3.6 迪米特法则LoD与KISS只和“朋友”说话保持简单迪米特法则Law of Demeter常被记作“最少知道原则”一个对象应该对其他对象有最少的了解。通俗说不要链式调用a.b.c.d.method()而应让a提供a.doSomething()方法。KISSKeep It Simple, Stupid则是对复杂度的终极警告。看一个违反LoD的典型链式调用# 用户下单后要获取其所在城市的GDP排名 gdp_rank user.profile.address.city.economic_data.gdp_rank这里user对象层层深入暴露了profile、address、city、economic_data四个中间对象的内部结构。问题在于一旦address类重构比如把city改为location这行代码立即报错user类本不该知道economic_data的存在它只该关心“我的城市GDP排名是多少”这个业务问题。LoD的解决方案是“封装导航”让对象自己回答问题class User: def __init__(self, profile): self.profile profile def get_city_gdp_rank(self) - int: User自己封装了如何获取GDP排名的路径 if not self.profile or not self.profile.address or not self.profile.address.city: return 0 return self.profile.address.city.get_gdp_rank() # 委托给city class City: def __init__(self, economic_data): self.economic_data economic_data def get_gdp_rank(self) - int: return self.economic_data.gdp_rank # 调用方现在只需 gdp_rank user.get_city_gdp_rank() # 简单、稳定、语义清晰User类承担了导航的责任对外隐藏了内部结构。即使未来City的economic_data被合并到City自身只需改City.get_gdp_rank()的实现User.get_city_gdp_rank()和所有调用方代码完全不受影响。KISS原则则提醒我们当一个设计开始需要画UML图、写10页文档才能让人看懂时它大概率已经过载了。比如为支持“未来可能的多租户”而提前在所有模型上加tenant_id字段或为“理论上需要的扩展性”而引入五层抽象工厂。真实项目中80%的“未来需求”永远不会来而100%的过度设计都会增加当前的维护成本。我的经验是先用最直接的方式实现当前需求当同一个模式重复出现3次以上时再提取抽象。比如当第3个API客户端都需要处理token刷新、重试、超时才去写BaseAPIClient当第3个数据类都需要JSON序列化/反序列化才去写SerializableMixin。简单不是偷懒而是对复杂度的敬畏。4. 从理论到落地一个真实订单系统的渐进式重构纸上谈兵终觉浅。下面用一个真实的中型电商订单系统重构案例展示如何将三大特性和六大原则串联起来解决实际问题。这个系统最初由实习生快速搭建核心是Order类约1200行包含订单管理、库存扣减、物流跟踪、发票生成、风控校验、优惠券计算、积分发放、短信通知等全部逻辑。上线三个月后每次加一个新功能如“企业客户专属运费险”平均要改87行代码平均引发3.2个回归Bug。4.1 第一阶段识别腐化信号划定重构边界重构不是重写而是有策略的渐进式改进。第一步是诊断哪些代码最痛我们用三个指标筛选指标计算方式高风险阈值本系统TOP3修改频率过去30天Git提交次数≥5次Order.calculate_final_price()(12次)圈复杂度radon cc分析≥15Order.process_payment()(23)测试覆盖率pytest --cov≤30%Order.generate_invoice()(8%)聚焦calculate_final_price()——它负责整合优惠券、满减、会员折扣、跨店满减、限时折扣等7种规则用嵌套if-else和全局状态变量实现。每次产品调整“满300减50”的门槛都要在这里改逻辑且极易影响其他折扣。重构目标明确将价格计算逻辑剥离使其可独立测试、可配置、可替换。这直接对应SRP单一职责、OCP新增折扣类型不改现有代码、DIP价格计算器依赖抽象协议。4.2 第二阶段定义协议实现策略注入依赖首先定义价格计算的抽象协议from typing import Protocol, List, Optional from dataclasses import dataclass dataclass class Discount: name: str amount: float description: str class PriceCalculator(Protocol): def calculate(self, base_price: float, order_items: List[Item], user: User) - tuple[float, List[Discount]]: 返回最终价格和应用的折扣列表 ...然后为每种折扣规则实现具体策略class CouponDiscount: def __init__(self, coupon_code: str, discount_amount: float): self.coupon_code coupon_code self.discount_amount discount_amount def calculate(self, base_price: float, order_items: List[Item], user: User) - tuple[float, List[Discount]]: if user.has_valid_coupon(self.coupon_code): final max(0, base_price - self.discount_amount) return final, [Discount(Coupon, self.discount_amount, fUse {self.coupon_code})] return base_price, [] class MemberDiscount: def __init__(self, member_tier: str, rate: float): self.member_tier member_tier self.rate rate def calculate(self, base_price: float, order_items: List[Item], user: User) - tuple[float, List[Discount]]: if user.tier self.member_tier: discount base_price * self.rate return base_price - discount, [Discount(Member, discount, f{self.member_tier} discount)] return base_price, []关键一步修改Order类移除原有计算逻辑注入PriceCalculatorclass Order: def __init__(self, items: List[Item], user: User, price_calculator: PriceCalculator): self.items items self.user user self._price_calculator price_calculator # 依赖倒置 self._base_price sum(item.price * item.quantity for item in items) property def final_price(self) - float: 单一职责只负责委托计算不参与逻辑 final, _ self._price_calculator.calculate( self._base_price, self.items, self.user ) return final
