OOD 模块 9: SOLID 原则

1

为什么需要 SOLID？

在前面的八个模块中，我们学习了面向对象设计的核心概念：类与对象、封装、继承、多态、组合、接口和设计模式。然而，仅仅了解这些概念还不够 —— 我们需要一套指导原则来确保我们的设计是健壮的、灵活的和可维护的。

SOLID 是由 Robert C. Martin（"Uncle Bob"）在 2000 年代初提出的五个面向对象设计原则的首字母缩写。这些原则相互补充，共同帮助开发者构建更好的软件系统。

字母	原则	核心思想
S	单一职责原则 (SRP)	一个类只应有一个变化的原因
O	开闭原则 (OCP)	对扩展开放，对修改关闭
L	里氏替换原则 (LSP)	子类必须能替代其父类
I	接口隔离原则 (ISP)	不应强迫客户端依赖不需要的接口
D	依赖倒置原则 (DIP)	高层模块不应依赖低层模块，两者都应依赖抽象

表 1 — SOLID 五大原则概览

为什么要学 SOLID？

遵循 SOLID 原则可以帮助你：(1) 降低类之间的耦合度；(2) 使代码更容易测试；(3) 使系统更容易扩展新功能而不破坏已有代码；(4) 提高代码的可读性和可维护性。

我们将继续使用在线书店作为贯穿全部原则的示例领域。让我们逐一深入了解每个原则。

2

单一职责原则 (SRP)

定义：一个类应当只有一个引起它变化的原因。换句话说，一个类应当只负责一项职责。

当一个类承担了过多职责时，任何一个职责的变更都可能影响到其他职责，导致代码脆弱且难以维护。SRP 要求我们将不同的关注点分离到不同的类中。

违反 SRP 的示例

考虑一个 Order 类，它同时负责订单数据管理、价格计算、数据库持久化和邮件通知：

Python

# 反面示例：一个类承担了太多职责
class Order:
    def __init__(self, order_id: str, items: list):
        self.order_id = order_id
        self.items = items

    def calculate_total(self) -> float:
        # 职责 1：计算价格
        return sum(item.price * item.quantity for item in self.items)

    def save_to_database(self):
        # 职责 2：数据库持久化
        db.execute("INSERT INTO orders ...", self.order_id)

    def send_confirmation_email(self):
        # 职责 3：发送邮件通知
        email_service.send(self.order_id, "订单已确认")

    def generate_invoice_pdf(self):
        # 职责 4：生成 PDF 发票
        pdf_builder.create_invoice(self)

问题所在

如果邮件服务的 API 变了，我们需要修改 Order 类。如果数据库表结构变了，也要改这个类。这个类有四个变化的原因，严重违反了 SRP。

遵循 SRP 的重构

我们将每个职责提取到独立的类中：

Python

# 正确示例：每个类只有一个职责
class Order:
    """仅负责订单数据和业务规则"""
    def __init__(self, order_id: str, items: list):
        self.order_id = order_id
        self.items = items

    def calculate_total(self) -> float:
        return sum(item.price * item.quantity for item in self.items)


class OrderRepository:
    """仅负责订单持久化"""
    def save(self, order: Order):
        db.execute("INSERT INTO orders ...", order.order_id)

    def find_by_id(self, order_id: str) -> Order:
        return db.query("SELECT * FROM orders WHERE id = ?", order_id)


class OrderNotifier:
    """仅负责订单通知"""
    def send_confirmation(self, order: Order):
        email_service.send(order.order_id, "订单已确认")


class InvoiceGenerator:
    """仅负责发票生成"""
    def generate_pdf(self, order: Order):
        pdf_builder.create_invoice(order)

SRP 核心要点

SRP 并不是说一个类只能有一个方法，而是说一个类的所有方法应该服务于同一个变化原因。当你发现一个类需要因不同的原因而改变时，就是拆分它的时候了。

3

开闭原则 (OCP)

定义：软件实体（类、模块、函数等）应当对扩展开放，对修改关闭。即你应该能够在不修改现有代码的情况下扩展系统的行为。

OCP 是 SOLID 中最具影响力的原则之一。它鼓励我们通过抽象和多态来设计系统，使得添加新功能时不需要修改已有的、经过测试的代码。

违反 OCP 的示例

假设我们的书店需要支持多种折扣策略。以下是一种常见但违反 OCP 的实现方式：

Python

# 反面示例：每新增一种折扣类型就要修改这个类
class DiscountCalculator:
    def calculate(self, order: Order, discount_type: str) -> float:
        total = order.calculate_total()
        if discount_type == "percentage":
            return total * 0.9
        elif discount_type == "fixed":
            return total - 10.0
        elif discount_type == "buy_two_get_one":
            # 买二送一逻辑...
            return total * 0.67
        # 每次新增折扣类型都要在这里添加分支！
        return total

遵循 OCP 的重构

通过抽象基类和策略模式，我们可以在不修改现有代码的情况下添加新的折扣策略：

Python

from abc import ABC, abstractmethod

class DiscountStrategy(ABC):
    """折扣策略的抽象基类"""
    @abstractmethod
    def apply(self, total: float) -> float:
        pass


class PercentageDiscount(DiscountStrategy):
    def __init__(self, rate: float):
        self.rate = rate  # 例如 0.1 表示九折

    def apply(self, total: float) -> float:
        return total * (1 - self.rate)


class FixedDiscount(DiscountStrategy):
    def __init__(self, amount: float):
        self.amount = amount

    def apply(self, total: float) -> float:
        return max(0, total - self.amount)


class MemberDiscount(DiscountStrategy):
    """新增会员折扣 —— 无需修改任何现有代码！"""
    def apply(self, total: float) -> float:
        return total * 0.85  # 会员享八五折


class DiscountCalculator:
    """对修改关闭：这个类不需要因新折扣类型而改变"""
    def calculate(self, order: Order, strategy: DiscountStrategy) -> float:
        return strategy.apply(order.calculate_total())

OCP 的关键

OCP 的核心在于抽象。通过定义稳定的抽象接口，具体实现可以自由变化和扩展。策略模式、模板方法模式和装饰器模式都是实现 OCP 的常用手段。

4

里氏替换原则 (LSP)

定义：如果 S 是 T 的子类型，那么程序中使用 T 类型对象的地方都可以用 S 类型对象替换，而不会改变程序的正确性。

LSP 由 Barbara Liskov 于 1987 年提出，是正确使用继承的基础。违反 LSP 意味着子类破坏了父类的行为契约，这会导致难以预料的 bug。

违反 LSP 的经典示例

在书店系统中，假设我们有一个 Book 类和一个 DigitalBook 子类：

Python

class Book:
    def __init__(self, title: str, price: float, weight: float):
        self.title = title
        self.price = price
        self.weight = weight  # 重量（千克）

    def get_shipping_cost(self) -> float:
        return self.weight * 5.0  # 按重量计算运费


class DigitalBook(Book):
    def __init__(self, title: str, price: float):
        super().__init__(title, price, weight=0)

    def get_shipping_cost(self) -> float:
        # 数字图书没有运费，但如果调用方期望正数呢？
        raise NotImplementedError("数字图书不需要运费")

违反 LSP

任何使用 Book 对象调用 get_shipping_cost() 的代码，在传入 DigitalBook 时都会抛出异常。子类不能安全地替代父类，违反了 LSP。

遵循 LSP 的重构

正确的做法是重新设计继承层次结构，使用抽象基类：

Python

from abc import ABC, abstractmethod

class Product(ABC):
    """所有产品的抽象基类"""
    def __init__(self, title: str, price: float):
        self.title = title
        self.price = price

    @abstractmethod
    def get_shipping_cost(self) -> float:
        pass


class PhysicalBook(Product):
    def __init__(self, title: str, price: float, weight: float):
        super().__init__(title, price)
        self.weight = weight

    def get_shipping_cost(self) -> float:
        return self.weight * 5.0


class DigitalBook(Product):
    def get_shipping_cost(self) -> float:
        return 0.0  # 数字图书运费为零 —— 契约满足！


# 任何使用 Product 的代码都可以安全地调用 get_shipping_cost()
def calculate_order_shipping(products: list[Product]) -> float:
    return sum(p.get_shipping_cost() for p in products)

LSP 检验法则

检验 LSP 的简单方法：将父类替换为子类后，所有调用方的代码是否仍然正确工作？子类是否增强而非削弱了父类的契约？如果子类需要抛出新异常或限制输入范围，那就是违反 LSP 的信号。

5

接口隔离原则 (ISP)

定义：不应该强迫客户端依赖它们不使用的接口。应该将臃肿的接口拆分为更小、更具体的接口。

ISP 与 SRP 密切相关，但关注点不同。SRP 关注的是类的职责，ISP 关注的是接口的粒度。一个"胖接口"会迫使实现者提供它们不需要的方法。

违反 ISP 的示例

Python

from abc import ABC, abstractmethod

class BookstoreService(ABC):
    """一个过于庞大的接口"""
    @abstractmethod
    def search_books(self, query: str) -> list: pass

    @abstractmethod
    def place_order(self, order: Order): pass

    @abstractmethod
    def process_payment(self, amount: float): pass

    @abstractmethod
    def generate_report(self) -> str: pass

    @abstractmethod
    def manage_inventory(self, book_id: str, qty: int): pass


# 问题：一个只需要搜索功能的客户端也被迫实现所有方法
class BookSearchWidget(BookstoreService):
    def search_books(self, query):
        return ["结果..."]

    # 被迫实现不需要的方法
    def place_order(self, order): raise NotImplementedError
    def process_payment(self, amount): raise NotImplementedError
    def generate_report(self): raise NotImplementedError
    def manage_inventory(self, book_id, qty): raise NotImplementedError

遵循 ISP 的重构

将大接口拆分为多个小而专注的接口：

Python

from abc import ABC, abstractmethod

class Searchable(ABC):
    """搜索能力"""
    @abstractmethod
    def search_books(self, query: str) -> list: pass


class OrderProcessing(ABC):
    """订单处理能力"""
    @abstractmethod
    def place_order(self, order: Order): pass


class PaymentProcessing(ABC):
    """支付处理能力"""
    @abstractmethod
    def process_payment(self, amount: float): pass


class Reporting(ABC):
    """报告生成能力"""
    @abstractmethod
    def generate_report(self) -> str: pass


class InventoryManagement(ABC):
    """库存管理能力"""
    @abstractmethod
    def manage_inventory(self, book_id: str, qty: int): pass


# 现在客户端只需实现它真正需要的接口
class BookSearchWidget(Searchable):
    def search_books(self, query: str) -> list:
        return ["结果..."]


# 需要多种能力的服务可以组合多个接口
class FullBookstoreService(Searchable, OrderProcessing, PaymentProcessing):
    def search_books(self, query): return ["结果..."]
    def place_order(self, order): pass
    def process_payment(self, amount): pass

ISP 与 Python

Python 支持多重继承，因此可以通过让类继承多个小型 ABC 来组合接口。这种做法有时也叫做 mixin 模式。关键是：客户端代码只应依赖于它实际使用的方法集合。

6

依赖倒置原则 (DIP)

定义：(A) 高层模块不应该依赖低层模块，两者都应该依赖抽象。(B) 抽象不应该依赖细节，细节应该依赖抽象。

DIP 是 SOLID 中最深刻的原则之一。传统的分层架构中，高层业务逻辑直接依赖低层实现（如数据库、文件系统）。DIP 要求我们反转这种依赖关系，让高层和低层都依赖于抽象接口。

违反 DIP 的示例

Python

# 反面示例：高层模块直接依赖低层实现
class MySQLDatabase:
    def save_order(self, order_data: dict):
        print(f"保存到 MySQL: {order_data}")


class OrderService:
    """高层业务逻辑 —— 直接依赖具体的 MySQL 实现"""
    def __init__(self):
        self.db = MySQLDatabase()  # 紧耦合！

    def create_order(self, customer: Customer, items: list):
        order = Order(customer, items)
        self.db.save_order(order.to_dict())
        return order

紧耦合的危害

如果我们想从 MySQL 切换到 PostgreSQL 或 MongoDB，就必须修改 OrderService 的代码。更糟糕的是，我们无法在不连接真实数据库的情况下测试 OrderService。

遵循 DIP 的重构

Python

from abc import ABC, abstractmethod

# 抽象层 —— 高层和低层都依赖于此
class OrderRepository(ABC):
    @abstractmethod
    def save(self, order_data: dict):
        pass

    @abstractmethod
    def find_by_id(self, order_id: str) -> dict:
        pass


# 低层实现 —— 依赖于抽象
class MySQLOrderRepository(OrderRepository):
    def save(self, order_data: dict):
        print(f"保存到 MySQL: {order_data}")

    def find_by_id(self, order_id: str) -> dict:
        return {"id": order_id}


class MongoOrderRepository(OrderRepository):
    def save(self, order_data: dict):
        print(f"保存到 MongoDB: {order_data}")

    def find_by_id(self, order_id: str) -> dict:
        return {"_id": order_id}


# 高层模块 —— 通过构造函数注入依赖于抽象
class OrderService:
    def __init__(self, repo: OrderRepository):
        self.repo = repo  # 依赖于抽象，而非具体实现

    def create_order(self, customer: Customer, items: list):
        order = Order(customer, items)
        self.repo.save(order.to_dict())
        return order


# 使用 —— 在组装阶段选择具体实现
service = OrderService(MySQLOrderRepository())
# 或者轻松切换：
service = OrderService(MongoOrderRepository())

依赖注入

依赖注入 (DI) 是实现 DIP 的最常用手段。通过构造函数、setter 或参数将依赖传入，而非在类内部创建依赖对象。这样做有三大好处：(1) 可测试性 —— 可以注入 mock 对象；(2) 灵活性 —— 可以轻松替换实现；(3) 透明性 —— 类的依赖一目了然。

DIP 与测试

DIP 的一个重要优势是大幅提升可测试性。通过注入模拟对象，我们可以在不依赖外部系统的情况下测试业务逻辑：

Python

# 测试用的模拟实现
class FakeOrderRepository(OrderRepository):
    def __init__(self):
        self.saved_orders = []

    def save(self, order_data: dict):
        self.saved_orders.append(order_data)

    def find_by_id(self, order_id: str) -> dict:
        return next(o for o in self.saved_orders if o["id"] == order_id)


# 单元测试 —— 无需数据库连接
def test_create_order():
    fake_repo = FakeOrderRepository()
    service = OrderService(fake_repo)
    service.create_order(customer, items)
    assert len(fake_repo.saved_orders) == 1

7

SOLID 实践

让我们通过一个综合示例来展示如何在实际系统中同时应用所有五个 SOLID 原则。我们将设计一个书店的购物车结账系统。

需求分析

购物车结账系统需要支持以下功能：

功能	说明	对应原则
商品管理	添加、移除购物车中的商品	SRP
价格计算	支持多种折扣策略	OCP
产品多态	实体书和电子书统一处理	LSP
支付处理	支持多种支付方式	ISP
持久化	订单存储可替换	DIP

表 2 — 需求与 SOLID 原则的对应关系

综合设计实现

Python

from abc import ABC, abstractmethod
from dataclasses import dataclass, field
from typing import Protocol


# ── LSP：使用抽象基类确保子类可替换 ──
class Product(ABC):
    def __init__(self, title: str, price: float):
        self.title = title
        self.price = price

    @abstractmethod
    def get_shipping_cost(self) -> float:
        pass


class PhysicalBook(Product):
    def __init__(self, title: str, price: float, weight: float):
        super().__init__(title, price)
        self.weight = weight

    def get_shipping_cost(self) -> float:
        return self.weight * 5.0


class DigitalBook(Product):
    def get_shipping_cost(self) -> float:
        return 0.0


# ── OCP：折扣策略可以自由扩展 ──
class DiscountStrategy(ABC):
    @abstractmethod
    def apply(self, subtotal: float) -> float:
        pass


class NoDiscount(DiscountStrategy):
    def apply(self, subtotal: float) -> float:
        return subtotal


class SeasonalDiscount(DiscountStrategy):
    def __init__(self, rate: float):
        self.rate = rate

    def apply(self, subtotal: float) -> float:
        return subtotal * (1 - self.rate)


# ── ISP：细粒度的接口 ──
class PaymentGateway(ABC):
    @abstractmethod
    def charge(self, amount: float) -> bool:
        pass


class Notifier(ABC):
    @abstractmethod
    def send(self, message: str, recipient: str):
        pass


# ── DIP：持久化抽象 ──
class OrderRepository(ABC):
    @abstractmethod
    def save(self, order_data: dict): pass


# ── SRP：购物车只负责管理商品 ──
class ShoppingCart:
    """仅负责管理购物车中的商品"""
    def __init__(self):
        self.items: list[Product] = []

    def add(self, product: Product):
        self.items.append(product)

    def remove(self, product: Product):
        self.items.remove(product)

    def get_subtotal(self) -> float:
        return sum(p.price for p in self.items)

    def get_shipping(self) -> float:
        return sum(p.get_shipping_cost() for p in self.items)


# ── SRP：结账服务只负责协调结账流程 ──
class CheckoutService:
    """协调结账流程 —— 每个依赖都是抽象接口 (DIP)"""
    def __init__(
        self,
        payment: PaymentGateway,
        repo: OrderRepository,
        notifier: Notifier,
        discount: DiscountStrategy,
    ):
        self.payment = payment
        self.repo = repo
        self.notifier = notifier
        self.discount = discount

    def checkout(self, cart: ShoppingCart, email: str) -> bool:
        subtotal = cart.get_subtotal()
        shipping = cart.get_shipping()
        total = self.discount.apply(subtotal) + shipping

        if self.payment.charge(total):
            self.repo.save({"total": total, "items": len(cart.items)})
            self.notifier.send(f"订单已确认，总计: ¥{total:.2f}", email)
            return True
        return False

五项原则的协同作用

注意这个设计如何同时满足所有 SOLID 原则：SRP — 每个类只有一个职责；OCP — 新的折扣策略不需修改现有代码；LSP — PhysicalBook 和 DigitalBook 可互换使用；ISP — PaymentGateway、Notifier、OrderRepository 都是小接口；DIP — CheckoutService 依赖抽象而非具体实现。

SOLID 原则之间的关系

SOLID 的五个原则并非独立存在，它们相互支撑、相互强化：

原则

关联

SRP

↔

ISP：拆分职责 = 拆分接口

OCP

↔

DIP：依赖抽象使扩展成为可能

LSP

↔

OCP：正确的继承保证安全扩展

ISP

↔

SRP：小接口促进单一职责

DIP

↔

LSP：抽象的子类必须可替换

8

总结

SOLID 原则是面向对象设计的基石。它们为我们提供了一套经过实践检验的指导方针，帮助我们构建更健壮、更灵活、更易维护的软件系统。以下是每个原则的关键要点：

S — 单一职责原则

一个类只应有一个变化的原因。将不同的关注点分离到独立的类中，降低变更的影响范围。

O — 开闭原则

对扩展开放，对修改关闭。通过抽象和多态实现功能扩展，避免修改已有的稳定代码。

L — 里氏替换原则

子类必须能安全替代父类。确保继承关系中的行为一致性，不要在子类中削弱父类的契约。

I — 接口隔离原则

不强迫客户端依赖不需要的接口。将大接口拆分为小而专注的接口，提高内聚性和灵活性。

D — 依赖倒置原则

高层模块和低层模块都依赖于抽象。通过依赖注入解耦组件，提高可测试性和可替换性。

实践建议

SOLID 原则是指导方针，而非铁律。在实际开发中，应根据项目规模和复杂度灵活运用。过度设计和欠设计同样有害。关键是在代码开始变得难以维护时，识别出违反了哪个原则，并进行有针对性的重构。