设计模式：面向对象的设计原则

开放/封闭原则

概述：

• 类或对象及其方法对于扩展来说，应该是开放的；
• 对于修改来说，应该是封闭的.

详细描述：

• 需要拓展类或对象行为时不必修改类本身；
• 为实现所需行为，用户必须同构拓展抽象基类创建类的实现，而不是通过修改抽象类.

优点：

• 现有的类不会被修改，因此退化的可能性较小；
• 有助于保持以前代码的向后兼容性.

控制反转原则

概述：

• 高层次的模块不应该依赖于底层级的模块，它们应该都依赖于抽象；
• 细节应该依赖于抽象，而不是抽象依赖于细节.

详细描述：

• 该原则建议两个模块都不应以紧密方式相互依赖。事实上，基本模块和从属模块应当在它们之间 提供要给抽象层来耦合；
• 这个原则还建议，类的细节应该描绘抽象。应当避免细节本身决定了抽象.

优点：

• 消弱了模块间的紧耦合，因此消除了系统中的复杂性/刚性；
• 由于在依赖模块之间又一个明确的抽象层（由钩子或参数提供），因此便于通过更好的方式处理模块之间的依赖关系.

接口隔离原则

概述：

• 客户端不应该依赖于它们不需要使用的接口

详细描述：

• 开发的方法要与特定功能紧密相关。如果存在与接口无关的方法，那么依赖于该接口的类就要实现它，实际上是无必要的；
• 例如，一个Pizza接口不应该提供名为add_chicken()的方法。基于Pizza接口的Veg Pizza类不应该强制实现该方法.

优点：

• 强制开发人员编写“瘦身型”接口，并使方法与接口紧密相关；
• 防止像接口随意添加方法.

单一职责原则

概述：

• 类的职责单一，引起类变化的原因单一

详细描述：

• 类应该为特定功能服务。如果一个类实现了两个功能，那么最好将它们分开；
• 功能才是改变的理由；
• 如果一个类会因为两个以上的因素（通常是功能改变）而改变，那么该类就应该进行相应的分割.

优点：

• 每当一个功能发生变化时，除了特定的类需要改变外，其他类无需变动；
• 如果一个类有多种功能，那么依赖它的类必定会由于多种原因而经历多次修改，这是应当避免的.

替换原则

概述：

• 派生类能够完全取代基类

详细描述：

• 当应用程序开发人员编写派生类时，应该尽可能对基类封闭，以至于派生类本身可以直接替换基类

优点：

• 避免对派生类的修改影响基类