设计模式——6大设计原则笔记

反复看了最起码有10遍。最后用1句话总结一下6大原则：
1.单一职责：一个类，一个方法只做一件事。
2.里氏替换：父类可以出现的地方，子类都可以出现。反之不行
3.依赖倒置：实体类之间不产生依赖，采用接口或抽象类调用
4.接口隔离：接口设计简单，类实现的接口尽量少。
5.迪米特法则：保持类的高内聚低耦合，不需要碰的一点都不碰
6.开闭原则：对系统的后期扩展，尽可能的减少代码修改，以增加新的代码实现扩展。而不是大量的修改代码。

---

---

今天刚开始系统化的学习设计模式。比起一年前什么基础都没有看的一头雾水，现在终于能懂了！！但还是理解的不太好。所以即时总结一下，以后经常拿起来巩固。
本文只是做了一部分概念总结性工作，且没有代码，类似于笔记。随着反复阅读，将会逐渐丰富。具体内容还请详阅 【设计模式之禅】

6大设计原则：单一职责原则、里氏替换原则、依赖倒置原则、接口隔离原则、迪米特法则、开闭原则。
（这个真不是一两天就能懂得啊，刚刚才过了一遍，现在回头再看这些名字，傻傻分不清楚……多看两遍就好了哈哈。）

在开始总结前，先回顾一些名词：依赖、关联、聚集、组合、耦合（紧耦合、松耦合、解耦）

依赖：表示一个类依赖另一个类的定义。java语言中体现为局部变量、方法的形参或静态方法的调用。
关联：类与类之间的的联接，使一个类知道另一个类的属性和方法（单项、双向）。java语言中体现为成员变量。
聚合： 是关联的一种，是强的关联关系。是整体和个体之间的关系。关联关系涉及的两个类是在同一层次上的，而聚合不在平等层次，一个代表整体、一个代表部分。
组合： 是关联的一种，比聚合强的关联关系。它要求普通的聚合关系中 代表整体 的对象负责 代表部分 对象的生命周期，组合关系是不能共享的。(有些拗口，我用斜体分隔开)
上述关系具体代码实现 参考博文http://blog.csdn.net/forrest420/article/details/5295516
耦合耦合度就是对象之间的依赖性。指导使用和维护对象的主要问题是对象之间的多重依赖性。对象之间的耦合越高，维护成本越高。因此对象的设计应使类和构件之间的耦合最小。
（只有这个时候才发现uml的重要啊，之后还要复习一下类图相关的知识）

【单一职责原则——SRP】
定义：
应该有且仅有一个原因引起类的变更。不要存在多于一个导致类变更的原因。通俗的说，即一个类只负责一项职责。某些时候，是对接口实现单一职责。

单一职责适用接口、类、方法。
拿方法举例：在业务层中，尽量让一个方法颗粒度变细。用户类，修改密码和修改名字分开来。不要直接传入一个用户value类进去修改。

对于单一职责原则，建议接口一定要做到单一职责，类的设计尽量做到一直有一个原因引起变化。

单一职责优势： 类的复杂性降低。可读性提高。维护性提高，变更引起的风险降低。

【里氏替换原则——LSP】
定义：
通俗点讲，只要父类能出现的地方子类就可以出现，而且替换为子类也不会产生任何错误或异常，使用者可能根本就不需要知道父类还是子类。但是，反过来就不行了。有子类出现的地方，父类未必能适应。

定义的四层含义
1.子类必须完全实现父类的方法。
2.子类可以有自己的个性
3.覆盖或实现父类的方法时输入参数可以被方法
（子类中方法的前置条件必须与超类中的被覆写的方法的前置条件相同或者宽松）
4.覆写或实现父类的方法时输出结果可以被缩小。

要点
在使用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀——委屈了点；把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离——缺乏类替换的标准。

【依赖倒置原则——DIP】
定义
高层模块不应该依赖底层模块，两者都应该依赖其抽象；
抽象不应该依赖细节
细节应该依赖抽象

在java中的体现是：
模块间的依赖通过抽象发生，实现类之间不发生直接依赖关系，其依赖关系式通过接口或抽象类产生的；
接口或抽象类不依赖实现类；
实现类依赖接口或抽象类。

依赖的三种写法
1.构造函数传递依赖对象
2.Seeter方法传递依赖对象
3.接口中声明依赖对象

要点
1.每个类尽量都有接口和抽象类，或者两个都具备
2.变量的表面类型尽量是接口或者抽象类
3.任何类都不应该从具体类派生
4.尽量不要复写基类的方法
5.结合里氏替换原则使用

【接口隔离原则】
定义
首先说接口分为两种：实例接口 （类的实例） 类接口（interface）
通俗一点讲接口隔离原则：简历单一的接口，不要建立臃肿庞大的接口。接口尽量细化，同时接口中的方法尽量少。

要点：
1.接口尽量要小
（根据接口隔离原则拆分接口时，首先必须满足单一职责原则）
2.接口要高内聚
3.定制服务
4.接口设计师有限度的。

1.一个接口只服务于一个子模块或业务逻辑
2.通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是肥嘟嘟的一大堆方法
3.已经被污染的接口，尽量去修改，若变更的风险较大，则采用适配器模式进行转化处理。
4.了解环境，拒绝盲从。不同环境，接口拆分的标准就不同。

【迪米特法则】
定义
也称最少知识原则，一个对象应该对其他对象有最少的了解。通俗的讲：一个类应该对自己调用或需要耦合的类知道的最少。我只知道你提供给我的Public方法，其他的一概不管。

要点
（这一块要点书上讲的比较抽象，我用自己的理解大概描述一下）
1.只和朋友交流
场景描述：A调用B来操作C。A→B→C
A调用B，那么A和B可以算是朋友。B操作C，B和C算是朋友。这里A和C就不是朋友。按照迪米特法则，A在调用B的过程中，对于C一点都不涉及，我只是调用了B的某个方法，告诉B去操作C吧，但是C是什么，A完全不知道。

2.朋友间也是有距离的
尽量减少类过多的public方法，考虑是否可以修改为其他访问权限。

3.是自己的就是自己的
如果一个类放在本类中，即不增加类间关系，也对本类不产生负面影响，就放在本类中。

4.谨慎使用序列化
这个没有太理解。

【开闭原则】
定义
对扩展开放，对修改关闭。

开闭原则是对前面的几种原则的总结，并没有太多的要点。
以我的理解，其核心的价值就是以最优的办法应对后期的功能扩展和修改。

在项目的后期扩展和修改中，尽量做到用增加代码来实现，而很少去大面积修改代码实现。
以目前不多的开发经验来看，实现这种原则最直接简单的办法就是采用接口调用，工厂模式。

参考博文：
http://blog.csdn.net/zhengzhb/article/details/7278174