设计模式的六大原则

标签：六大 依赖 原则 父类 接口 Principle 模块 设计模式

开放封闭原则（Open Close Principle） 对外扩展是开放的，对内修改是封闭的，目的是保证程序的可扩展性以及可维护性   里氏代换原则（Liskov Substitution Principle） 子类可以扩展父类的功能，但不能改变父类原有的功能。 规定了子类不得重写父类的普通方法，只能重写父类的抽象方法，如果在设计软件时要继承的话，设计继承抽象类而不是直接继承普通类 保证了父类的复用性，不会破坏继承的机制，降低系统故障几率   依赖倒转原则（Dependence Inversion Principle） 高层模块不应该依赖于底层模块，细节应该依赖抽象、接口。 相对于细节的多变性，抽象的东西会更加稳定，以抽象为基础搭建起来的架构比以细节为基础搭建起来的架构要稳定的多。 问题：类A直接依赖类B，假如要将类A改为依赖类C，则必须通过修改类A的代码来达成。 这种场景下，类A一般是高级模块，类B和类C是低级模块，负责基本的原子操作，假如要修改类A的话，会给程序带来不必要的风险。 解决方案：将类A修改为依赖接口1，类B和类C各自实现接口1，通过接口间接与类B或者类C发生联系，则会大大降低修改类A的几率。   接口隔离原则（Interface Segregation Principle）

1. 用户不应该依赖与他不需要的接口
2. 类间的依赖关系应该建立在最小的接口上

通俗来讲就是尽量将接口细化，同时保证接口中的方法尽量的少。   迪米特法则（最少知道原则）（Demeter Principle） 一个对象应该对其他对象有最少的了解

• 从依赖者的角度来说，只依赖应该依赖的对象
• 从被依赖者的角度来说，只暴露应该暴露的方法

优点：

• 降低了类之间的耦合度，提高了模块的相对独立性
• 提高了类的可复用性以及系统的延展性

  单一职责原则（Principle of single responsibility） 对一个类而言，应该仅有一个引起他变化的原因。如果存在多于一个动机去改变一个类，那么这个类就具有多于一个的职责，就应该把多于的职责分离出去，再去创建一些类来完成每一个职责。 优点：

• 降低类的复杂度，实现高内聚，低耦合
• 提高类的可读性，提高系统的可维护性
• 降低引起变更所带来的风险

 

标签：六大,依赖,原则,父类,接口,Principle,模块,设计模式
From： https://www.cnblogs.com/Yuansj0206/p/17630030.html