设计模式（一）

好久之前看设计模式的时候，也没有看的太透彻，一直到如今，仍是云里雾里，并且杂七杂八的知识早就忘得差很少了。

最近买了一本最经典的最基础的设计模式的书--《大话设计模式》，就此趁这机会在重学一遍，好好理一理思路。

六大原则

 

一、单一职责原则

字面理解，是要保持功能的单一，每一个类或方法要尽可能把实现的功能拆分出来，这样能保证低耦合，还能减小代码的重复量。

好比，从学生表中获取成绩大于90的学生，修改等级为A，若是放在一个方法里实现，那获取成绩大于90分的学生的功能就要从新写一个方法。

最好的办法是，将查询和修改写成两个方法，避免重用。这在mvc三层设计里就是常用的。

二、里氏替换原则

任何基类能够出现的地方，子类必定能够出现。

-->里氏替换原则规范（请参照：http://blog.csdn.net/hfreeman2008/article/details/52344343）

-->1）子类必须彻底实现父类的方法

-->2）子类能够有本身独有的方法和属性

-->3）覆盖或实现父类的方法时输入参数能够被放大

-->4）覆盖或实现父类的方法时输出结果能够被缩小

三、依赖倒转原则

抽象不该该依赖细节，细节应该依赖于抽象。高层模块不该该依赖于低层模块，二者都应该依赖于抽象。

若是是高层依赖于低层，在低层模块须要更改时也须要更改高层模块，会致使模块的复用性下降并且大大提升了开发的成本。因此用依赖倒转，即便实现细节不断变更，只要抽象不变，客户程序就不须要变化。这大大下降了客户程序与实现细节的耦合度。

四、接口隔离原则

客户端不该该依赖它不须要的接口；一个类对另外一个类的依赖应该创建在最小的接口上。

通常规则：

• 一个接口只服务于一个子模块或业务逻辑
• 接口尽可能简洁
• 接口尽可能不要更改

好比在简书上看到的一个例子：一个动物接口，一只狗，一只鸡，若是接口里定义了飞的方法，狗对象并不能使用。因此要再定义一个接口，将飞的方法放进去，由鸡来实现。

五、迪米特法则

一个软件实体应当尽量少的与其余实体发生相互做用。就是说一个对象应当对其余对象有尽量少的了解,不和陌生人说话。

1）优先考虑将一个类设置成不变类。

2）尽可能下降一个类的访问权限。

3）谨慎使用Serializable。

4）尽可能下降成员的访问权限。

六、开闭原则

软件实体，包括类、函数、模块等，能够扩展，但不能修改。简单来讲就是能够添加，不能改动。开闭原则中“开”，是指对于组件功能的扩展是开放的，是容许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即修改原有的代码对外部的使用是透明的。