Foundations of Object-Oriented Programming: The Building Blocks of Design Patterns

这些反模式并非偶然出现——它们本质上是面向对象编程的四大核心支柱被忽视或滥用的直接后果。要理解设计模式为何能解决这些问题，我们首先需要深入理解这四大支柱的实际价值，以及它们与反模式之间的对抗关系。很多初学者对OOP概念的理解停留在“知道定义”的层面，却无法在实际项目中灵活运用，最终写出的代码依然充满紧耦合和低内聚问题。本节我们将通过真实可运行的代码案例，把抽象的概念转化为可落地的开发实践。

1.3 深入解析OOP四大核心支柱：从理论到实践

我们之前已经简要介绍了封装、继承、多态、抽象四个核心概念，现在我们将通过对比“错误用法”和“正确用法”，深入理解每个概念的实际价值，以及忽视它们会带来的具体问题。

1.3.1 封装：隐藏实现，而非仅仅隐藏数据

很多初学者对封装的理解停留在“把属性设为私有”的层面，但封装的核心价值是隐藏实现细节，降低模块间的依赖。封装的核心原则是：外部调用者只需要知道“能做什么”，不需要知道“怎么做”。

我们先看一个违反封装原则的反模式代码： ```python

反模式：公开所有属性，无访问控制

class BadBankAccount: def __init__(self, owner: str, balance: float = 0): self.owner = owner self.balance = balance # 公开属性，外部可以随意修改

使用反模式代码的问题

account = BadBankAccount("Alice", 1000) account.balance = -1000000 # 非法操作，余额变成负数，没有校验 print(account.balance) # 输出-1000000，出现严重业务逻辑错误 ``` 这个代码的问题非常典型：`balance`属性是公开的，任何外部代码都可以随意修改，没有任何业务规则校验，最终导致数据不一致。而正确的封装做法是：把属性设为私有，只暴露必要的公共接口，在接口中添加业务规则校验： ```python

正确封装示例

class BankAccount: def __init__(self, owner: str, balance: float = 0): self.__owner = owner # 私有属性，外部无法直接访问 self.__balance = balance # 私有属性，外部无法直接访问

公共getter方法，只读暴露余额

@property def balance(self) -> float: return self.__balance

存款方法，添加金额校验

def deposit(self, amount: float) -> None: if amount <= 0: raise ValueError("存款金额必须大于0") self.__balance += amount

取款方法，添加余额校验

def withdraw(self, amount: float) -> None: if amount <= 0: raise ValueError("取款金额必须大于0") if amount > self.__balance: raise ValueError("余额不足") self.__balance -= amount

测试封装的好处

account = BankAccount("Alice", 1000) print(account.balance) # 输出1000，通过公共接口访问 account.deposit(500) # 正常存款 print(account.balance) # 输出1500

account.__balance = -1000 # 报错：AttributeError，无法直接修改私有属性

account.withdraw(2000) # 报错：余额不足，避免非法操作 ``` 这个例子展示了封装的两个核心价值： 1. 数据安全性：通过访问控制，避免外部代码随意修改内部数据，保证业务规则被严格执行。