面向对象设计原则与设计模式解析

# 面向对象设计原则与设计模式解析 ## 1. 面向对象设计原则 ### 1.1 接口隔离原则 接口隔离原则指出，客户端不应依赖它们不使用的接口，尤其不应依赖它们不使用的方法。在编程中，我们常使用接口来使代码更灵活和可维护，但容易犯的错误是将接口设计得过大。 当我们为了满足某个实现该接口的子类的需求，而向接口中添加其他子类不需要的新方法时，就会降低接口的内聚性，违反接口隔离原则。解决办法是创建更多的接口，将臃肿的接口拆分为两个或更多更小、内聚性更强的接口，这样新类就可以只实现它们需要的接口。 ### 1.2 最少知识原则 最少知识原则（PLK），也称为迪米特法则，它要求一个对象只与它的直接朋友通信。在应用程序中，强内聚的补充是松耦合，这正是最少知识原则的核心。该原则指出，类应尽可能少地与其他类间接协作。 例如，在编写一个绘制汽车温度数据的应用程序时，如果代码如下： ```java public void plotTemperature(Sensor theSensor) { double temp = theSensor.getSensorData().getOilData().getTemp(); ... } ``` 这样的代码会将`plotTemperature`方法与`Sensor`、`SensorData`和`OilSensor`类紧密耦合，任何一个类的更改都可能影响该方法，需要重构代码。 遵循最少知识原则，我们应直接请求数据： ```java public void plotTemperature(double theData) { ... } ... plotTemperature(aSensor.getTemp()); ``` 虽然需要在`Sensor`类中添加一个获取温度的方法，但这是清理之前混乱代码（以及可能的错误）的小代价。最少知识原则的一个推论是将依赖关系保持在最低限度，这是松耦合的关键。 ### 1.3 类设计准则 以下是 23 条类设计准则： 1. 在类接口中呈现一致的抽象级别。 2. 确保理解类正在实现的抽象。 3. 将不相关的信息移到不同的类中（接口隔离原则）。 4. 在进行更改时，注意类接口的侵蚀（接口隔离原则）。 5. 不要添加与接口抽象不一致的公共成员。 6. 最小化类和成员的可访问性（开闭原则）。 7. 不要公开成员数据。 8. 避免将私有实现细节放入类的接口中。 9. 避免将方法放入公共接口中。 10. 注意过紧的耦合（最少知识原则）。 11. 尝试通过类内的包含来实现“有一个”关系（单一职责原则）。 12. 通过继承实现“是一个”关系（里氏替换原则）。 13. 仅当派生类是基类的更具体版本时才进行继承。 14. 确保只继承你想要继承的内容（里氏替换原则）。 15. 将公共接口、数据和操作尽可能高地移到继承层次结构中（不要重复自己原则）。 16. 对只有一个实例的类保持怀疑。 17. 对只有一个派生类的基类保持怀疑。 18. 避免深继承树（里氏替换原则）。 19. 尽量减少类中的方法数量。 20. 最小化对其他类的间接方法调用（最少知识原则）。 21. 如果可能，在所有构造函数中初始化所有成员数据。 22. 消除仅包含数据的类。 23. 消除仅包含操作的类。 ## 2. 设计模式 ### 2.1 设计模式概述 设计模式就像代码模式一样，是设计的规则和模板。如果花时间学习一组核心的设计模式，将使代码更加统一、易读，并随着时间的推移提高其整体质量。 著名建筑师克里斯托弗·亚历山大在他的《建筑模式语言》一书中定义了建筑设计的模式，同样的思想也适用于软件设计。设计模式具有三个关键要素： - 重复性：引发设计模式的问题必须是常见的。 - 核心解决方案：模式提供解决方案的模板，试图提取解决方案的本质。 - 可复用性：当相同的问题出现在不同的领域时，模式必须易于复用。 ### 2.2 设计模式的分类 设计模式根据范围和目的进行分类： - 范围：处理类和对象之间的关系。类之间的静态关系在编译时固定，而对象之间的动态关系可以在运行时改变。 - 目的：处理类和对象的创建、组合或对象之间的