设计模式6大原则

设计模式6大原则

1.概述，23种设计模式在程序设计中具有广泛的应用，而这些 设计模式的产生与应用又遵循着核心的6原则。今天便跟大家分享这6大原则问题

2.六大原则：

单一职责原则（Single Responsibility Principle）

定义：应该有且只有一个原因引起类的变更

一个类，方法，接口只有一个单一职责。

当 一个类中含有两个不相互影响的职责时，那么我们就可以将这个类按照职责分为两个不同的类。

 

单一职责原则的好处：

类的复杂度降低了，实现什么职责都清晰定义了

可读性提高

可维护性提高

变更引起风险的可能降低：一个接口的改变只会印象本实现类/职责的变动

对单一职责原则的建议:接口一定做到单一原则，类的设计则尽可能满足：只有一个原因引起变化。

里氏替换原则

①定义1：如果对每一个类型T1的对象o1，都有类型T2的对象o2，是的以T1定义的所有程序p在所有的对象o1都代换成o2时，程序p的行为没有发生变化，那么类型T2是类型T1的子类型

   定义2：所有引用基类的地方必须能够透明的使用子类的对象。

②里氏替换的4个含义：

   子类必须完全实现父类的方法；

   子类可以有自己的个性

   覆盖或者实现父类的方法时，输入参数可以被放大。子类中方法的前置条件必须与超类中被覆盖的方法的前置条件相同或
者更宽松。就如同C++多态问题，切片

   覆盖或者实现父类的方法输出结果可以被缩小。这个是什么意思呢，父类的一个方法返回值是一个类型 T，子类相同方法(重载或重写)返回值为 S，那么里氏替换法则就要求 S 必须小于等于 T，也就是说要么S 和 T 是同一个类型，要么 S 是 T 的子类，为什么呢？分两种情况，如果是重写，方法的输入参数父类子类是相同的，两个方法的范围值 S 小于等于 T，这个是重写的要求，这个才是重中之重，子类重写父类的方法，
天经地义；如果是重载，则要求方法的输入参数不相同，在里氏替换法则要求下就是子类的输入参数大于等于父类的输入参数，那就是说你写的这个方法是不会被调用到的，参考上面讲的前置条件。

  里氏替换法则诞生的目的就是加强程序的健壮性，同时版本升级也可以做到非常好的兼容性，增加子类，原有的子类还可以继续运行。在我们项目实施中就是每个子类对应了不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑，非常完美！

 

依赖倒置原则

3层含义：

高层模块不应该依赖地层模块，两者都应该依赖其抽象

抽象不应该依赖细节

细节（实现类）应该依赖抽象

java表现：

   模块之间的依赖通过抽象发生，实现类之间不发生直接的依赖关系，其依赖关系通过接口或者抽象实现。

   接口或者抽象类不依赖实现类

   实现类依赖接口或者抽象类

依赖的三种写法

1 构造函数传递依赖对象

2 setter方法传递依赖对象

3 接口声明依赖对象

依赖倒置原则的本质是：通过抽象使各个类或者模块彼此独立，不相互影响，实现模块间的松耦合。

使用原则：

   每个类尽量使用接口或者抽象类，或者抽象类和接口两者都具备

   变量的表面类型尽量使接口或者抽象类

   任何类都不应该从具体类派生。

   尽量不复写基类的方法。--》类间依赖是抽象，复写抽象方法，对于依赖的稳定产生一定的影响。

   结合里氏替换原则使用

   是实现开闭原则的重要途径

 

接口隔离原则

定义1：客户端不应该依赖他不许用的接口。

定义2：类间的依赖关系应该建立在最小的接口上。

--->建立单一接口，不要建立比较臃肿的接口/接口细化，接口中的方法尽量少

把一个臃肿的接口变更为两个独立的接口依赖的原则就是接口隔离原则让类依赖两个专用的接口比一个综合的接口更灵活。

 

接口隔离原则4含义：

   接口尽量小   ->根据接口隔离原则进行接口拆分时，必须满足单一职责原则

   接口高内聚   ->接口中公布尽量少的public方法，承诺越少，出错越少

   定制服务     ->内部相同的实现，对不同的用户类型，public不同的接口

   接口的设计是有限度的 ->

 

衡量规则：

  一个接口只服务与一个子模块或者业务

  通过业务逻辑压缩接口中的public方法

  已经被污染的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理

  了解环境，拒绝盲从

 

迪米特法则->最少知识原则

定义：一个对象应该对其他对象有最少的了解。类对其需要调用的类的知道的最少。

--朋友之间也要保持距离。

--类要小气，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private，protected等权限

--是自己的就是自己的。如果一个方法放在本类中，既不增加类间关系，也不对本类产生负担，就放在本类中

--谨慎使用Serializable

迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高，其要求
的结果就是产生了大量的中转或跳转类，类只能和朋友交流，朋友少了你业务跑不起来，朋友多了，你项
目管理就复杂，大家在使用的时候做相互权衡吧。

 

开闭原则

软件实体应该对扩展开放，对修改关闭，其含义是说一个软件实体应该通过扩展实现变化，而不是通过修改实现改变。

 软件实体：项目或者软件产品中按照一定的逻辑规则划分的模块。

               抽象和类

               方法

 eg对于客户需求的某种改变，我们应该如何满足呢。

3中方法：1修改接口，2修改实现类，3通过扩展实现改变

注：开闭原则对扩展开放，对修改关闭，并不意味着不作任何修改，低层模块的变更，必然要有更高模块进行耦合。

变化三种类型：逻辑变化，子模块变化，可见视图变化。

 

开闭原则重要性：

1 开闭原则对测试的影响

2 开闭原则可以提高复用性

3 开闭原则可以提高可维护性

4 面向对象开发的要求

 

开闭原则的使用：

1 抽象约束

2 元数据控制模块行为

3 制定项目章程

4 封装变化。