java设计模式---

设计模式在软件中哪里？

面向对象 ==> 功能模块[设计模式+算法（数据结构）] ==> 框架[使用到多种设计模式] => 架构[服务器集群]

设计模式的七大原则

编写软件过程中，程序员面临着来自耦合性，内聚性以及可维护性，可扩展性，重用性，灵活性等多方面的挑战，设计模式是为了让程序（软件），具有更好的
1）代码重用性（即：相同功能的代码，不用多次编写）
2）可读性（即：编程规范性，便于其他程序员的阅读和理解）
3）可扩展性（即：当需要增加新的功能时，非常的方便，称为可维护
4）可靠性（即：当我们增加新的功能后，对原来的功能没有影响）
5）使程序呈现高内聚，低耦合的特性

设计模式原则，其实就是程序员在编程时，应当遵守的原则，也是各种设计模式的基础（即：设计模式为什么这样设计的依据）
我们设计 设计模式的原则 是：

	1）单一职责原则
	2）接口隔离原则
	3）依赖倒转（倒置）原则
	4）里氏替换原则
	5）开闭原则
	6）迪米特法则
	7）合成复用原则

单一职责原则

基本介绍
对类来说的，即一个类应该只负责一项职责。如类A负责两个不同职责：职责1，职责2。当职责1需求变更而改变A时，可能造成职责2执行错误，所以需要将类A的粒度分解为A1，A2。

应用案例
比如下面三种方案的代码：
方案一中，“公路上跑的” 和 “天上飞的” 都在一个类里面。如果某一天要对"公路上跑的"进行细分，那么就绝对会影响到 “天上飞的"的情况。
所以就有了方案二，即把"公路上跑的” 和 “天上飞的” 分成两个类。理论上满足单一职责原则，但是这里代码比较简单，这么分就太细了。你将类进行了分解，那么main函数中的调用就得 重写，定义两个类。
于是有了第三种方案，类级别不遵守单一职责原则，在方法级别上遵守单一职责原则。

单一职责原则注意事项和细节

1）降低类的复杂度，一个类只负责一项职责。
2）提高类的可读性，可维护性
3）降低变更引起的风险
4）通常情况下，我们应当遵守单一职责原则，只有逻辑足够简单，才可以在代码级违反单一职责原则；只有类中方法数量足够少，可以在方法级别保持单一职责原则

不要在一个函数里使用 if elseif else if else if
这样耦合性太高。可以像上面方法3一样，拆成多个方法。或者拆成多个类。

接口隔离原则（Interface Segregation Principle）

基本介绍

1）客户端不应该依赖它不需要的接口，即一个类对另一个类的依赖应该建立在最小的接口上
2）先看一张图：
3）类A通过接口Interfacel依赖类B，类c通过接口Interface1依赖类D，如果接口Interface1对于类A和类c来说不是最小接口那么类B和类D必须去实现他们不需要的方法。