[设计模式]设计模式的6大基本原则

标签：就是   另一个   编程   类之间的关系   了解   简单的   测试   类方法   基类   

1. 单一职责原则
   • 概念：不要存在多余一个导致类变更的原因；即一个类只负责一项职责；
   • 原因：如果类T负责两个不同的职责P1和职责P2，当职责P1需求发生改变而修改类T时，原本运行正常的职责P2可能故障；
   • 优点：降低类的复杂性；提高类的可读性；变更引起的风险降低
2. 里氏替换原则
   • 概念：所有引用基类的地方必须能透明地使用其子类的对象。子类可以扩展父类的功能，但不能改变父类原有的功能；
   • 原因：不遵循该原则，代码出错的概率会大大增加
   • 含义：
     1. 子类可以实现父类的抽象方法，但不呢个覆盖父类的非抽象方法；
     2. 子类中可以增加自己特有的方法；
     3. 当子类重载父类的方法时，方法的前置条件（即方法形参）要比父类方法的输入参数更加宽松；
     4. 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法返回值）要比父类更加严格；
3. 依赖倒置原则（核心思想：面向接口编程）
   • 概念：依赖于接口而不依赖于实现；依赖于抽象而不依赖于细节
   • 原因：类A直接依赖类B，假设将类A修改为依赖于类C，则需要修改类A中的代码。在这种场景下，类A一般是高层模块，负责复杂的业务逻辑；类B和类C是低层模块，负责基本的原子操作；假设修改类A，会给程序带来不必要的风险；
   • 解决方案：将类A修改为依赖于接口I，类B和类C各自实现接口I，类A通过接口I间接与类B或者类C发生关系，则会大大降低修改类A的几率；
4. 接口隔离原则
   • 概念：客户端不应依赖于它不需要的接口；一个类对另一个类的依赖应该建立在最小接口上；
   • 原因：类A通过接口I间接依赖类B，类C通过接口I间接依赖类D，如果接口I对于类A和类B来说不是最小接口，则类B和类D必须要去他们不需要的方法；
   • 解决方案：将臃肿的接口I拆分为独立的几个接口，类A和类C分别于他们需要的接口建立依赖关系；
5. 迪米特法则
   • 含义：最少知道原则，即一个类对自己依赖的类知道的越少越好。对于被依赖的类来说，无论逻辑多么复杂，都尽量地将逻辑封装在类的内部，对外除了提供public方法外，不对外泄露任何信息。更简单的定义：只与直接朋友通信 高内聚，低耦合，但是中介类不能过多，不然会增加系统复杂性
   • 概念：一个对象对其他对象保持最少的了解
   • 原因：类与类之间的关系越密切。耦合度越大，当一个类改变时，对另一个类的影响也越大。
   • 解决方案：尽量降低类与类之间的耦合。如何定义直接朋友：每个对象都会与其他对象有耦合关系，只要两个对象之间有耦合关系，我们就说这两个对象之间是朋友关系。耦合方式有多种，比如依赖，关联（聚合、组合）等。其中，我们称出现在成员变量、方法参数、方法返回值中的类位置没对象，而出现在局部变量中的类则不是直接朋友。也就是说，陌生的类最好不要做为局部变量的形式出现在类的内部。
6. 开闭原则
   • 概念：软件实体如类、模块、函数应该对扩展开放，对修改关闭
   • 原因：在软件的生命周期内，因为变化、升级和维护等原因需要对软件原有代码进行修改时，可能会源代码中引入错误，也可能会时我们不得不对整个功能进行重构，并且需要原有代码经过测试。
   • 解决方法：当软件需要变化时，尽量通过扩展软件实体的行为来实现比那话，而不是修改已有代码来实现变化。

[设计模式]设计模式的6大基本原则

标签：就是   另一个   编程   类之间的关系   了解   简单的   测试   类方法   基类   

原文地址：https://www.cnblogs.com/mrdragonma/p/13246980.html