设计模式之六大设计原则

利用这个寒假，把设计模式重新温习一遍，顺便做好笔记，所以接下来的笔记都是在看了《设计模式之禅》一书后做的总结

设计模式一共有六大原则，分别是单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则。

下面一一介绍这六个原则

单一职责原则

定义：应该有且仅有一个原因引起类的变更。也就是一个类或接口只有一个职责，它就负责一件事情。
单一职责的好处：
1）类的复杂性降低，实现的职责都有明确定义
2）可读性提高
3）可维护性提高
4）变更引起的风险降低。
但是在单一职责里最难划分的就是职责。职责和变化原因是不可度量的，因项目而异，因环境而异
我们在设计的时候，对于接口一定要单一，但是对于类，就要考虑多方面。生搬硬套只会使类的剧增，给维护带来很多麻烦。
单一原则对类和接口适用，同时对于方法也适用，一个方法只负责一件事。

里氏替换原则

定义：所有引用基类的地方必须能透明的使用其子类的对象。通俗讲，只要父类能出现的地方子类就可以出现，而且替换为子类不会出现任何错误和异常。但是反过来就不行了，有子类的地方，父类未必适应。
我们在做系统设计的时候，经常会定义一个接口或抽象类，然后编码实现，调用类则直接传入接口或抽象类。其实这里使用的就是里氏替换原则

依赖倒置原则

依赖倒置原则在Java中的表现就是，
1）模块之间的依赖通过抽象发生。实现类之间不发生直接的依赖关系，其依赖关系是通过接口或抽象类产生的。
2）接口或抽象类不依赖于实现类
3）实现类依赖于接口或抽象类
其实就是面向接口的编程

接口隔离原则

客户端需要什么接口就提供什么样子的接口，把不需要的接口剔除，那就需要接口细化。即建立单一接口，接口尽量细化，同时接口中的方法尽量少。注意，跟单一职责是有区别的，单一职责注重的是职责，业务逻辑上的划分，而接口隔离要求接口的方法尽量少。
专门的接口真的是什么？就是指提供给每个模块的都应该是单一接口，提供给几个模块就应该有几个接口，而不是建立一个庞大的臃肿的接口，容纳所有客户端访问。
接口隔离原则是对接口进行规范约束，其中包含四层含义：
1）接口尽量小
2）接口要高内聚
3）定制服务。只提供访问者需要的方法。
4）接口设计是有限度的。接口的设计粒度越小，系统越灵活。但是灵活的同时也带来了复杂化，开发难度增加，可维护性降低。

迪米特法则

一个对象应该对其他对象有最少的了解。
迪米特法则对类的低耦合提出了明确的要求，其中包含四层含义：
1）只和朋友交流。朋友的定义：出现在成员变量、方法的输入输出参数中的类称为成员朋友类。而出现在方法体内部的类不属于。
2）朋友间也是有距离的。意思就是尽量少提供public方法和属性。
3）是自己的就是自己的。如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。
4）谨慎使用serializable
迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合后类的复用率才可以提高。

开闭原则

软件实体如类、模块、函数应该对扩展开发，对修改关闭。
如果把开闭原则作为抽象类，那么前五个原则就是具体的实现类。