设计模式之禅《一》 大旗不挥，谁敢冲锋 ——6大设计原则

设计模式之禅《一》大旗不挥，谁敢冲锋 ——6大设计原则

《一》 六大原则

一：单一职责原则

1、单一职责原则最难划分的就是职责

2、有两个可以变化的原因放到了一个接口中，这就为以后的变化带来了风险。

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

禅：不同对象对同一个接口进行调用时，如果其中的某个方法产生不同的实现就应该把他抽离出来形成以自己为中心的新的职责。创建自己的接口时职责一定要清晰清晰！，单一，不要让别人猜测这个方法可能是用来处理什么逻辑的。

二：里氏替换原则

里氏替换原则，父类出现的地方子类就可以出现

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

2.子类可以有自己的个性

3.覆盖或实现父类的方法时输入参数可以被放大

4.覆写或实现父类的方法时输出结果可以被缩小

禅：程序的健壮性和兼容性（在实际项目中，每个子类对应不同的业务含义，使用父类作为参数，传递不同的子类完成不同的业务逻辑）在项目中，采用里氏替换原则时，尽量避免子类的“个性”，一旦子类有“个性”，这个子类和父类之间的关系就很难调和了，把子类当做父类使用，子类的“个性”被抹杀——委屈了 点；把子类单独作为一个业务来使用，则会让代码间的耦合关系变得扑朔迷离——缺乏类替换的标准。

三：依赖倒置原则 (适用于10人以上开发团队的大项目开发)

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

● 接口或抽象类不依赖于实现类；

● 实现类依赖接口或抽象类。

要协作就要并行开发，要并行开发就要解决模块之间的项目依赖关系，依赖倒置原则！

//我们只需要一个ICar的接口，就可以对Driver类进行单元测试。
public class DriverTest extends TestCase {
	Mockery context = new JUnit4Mockery (); 
    @Test
	public void testDriver( ){
	//根据接口虚拟一个对象
	final ICar car = context.mock(ICar.class) ;
        IDriver driver = new Driver () ;
	//内部类
	context.checking ( new Expectations ( ) { {
			oneof(car).run() ;
		} });
	driver.drive(car) ;
	}
}

只要做到抽象依赖，即使是多层的依赖传递也无所畏惧

1.构造函数传递依赖对象

2.-Setter方法传递依赖对象

3.接口声明依赖对象

禅:

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

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

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

● 尽量不要覆写基类的方法

● 结合里氏替换原则使用 (P-62)

四：接口隔离原则

● 接口要尽量小 根据接口隔离原则拆分接口时，首先必须满足单一职责原则。

● 接口要高内聚

具体到接口隔离原则就是，要求在接口中尽量少公布public方法，接口是对外的承诺，承诺越少对系统的开发越有利，变更的风险也就越少，同时也有利于降低成本。

● 定制服务

● 接口设计是有限度的

禅：

● 一个接口只服务于一个子模块或业务逻辑；

● 通过业务逻辑压缩接口中的public方法，接口时常去回顾，尽量让接口达到“满身筋骨肉”，而不是“肥嘟嘟”的一大堆方法；

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

● 了解环境，拒绝盲从。每个项目或产品都有特定的环境因素，别看到大师是这样做的你就照抄。千万别，环境不同，接口拆分的标准就不同。深入了解业务逻辑，最好的接口设计就出自你的手中！

五：迪米特法则

一个对象应该对其他对象有最少的了解 。

如果一个方法放在本类中，既不增加类间关系，也对本类不产生负面影响，那就放置在本类中。

禅：迪米特法则的核心观念就是类间解耦，弱耦合，只有弱耦合了以后，类的复用率才可以提高。

迪米特法则要求类“羞涩”一点，尽量不要对外公布太多的public方法和非静态的public变量，尽量内敛，多使用private、package-private、protected等访问权限。

六：开闭原则

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

通过扩展实现变化

增加一个子类OffNovelBook，覆写getPrice方法，高层次的模块（也就是static静态模块区）通过OffNovelBook类产生新的对象，完成业务变化对系统的最小化开发。好办法，修改也少，风险也小，

项目开发、重构、测试、投产、运维，其中的重构可以对原有的设计和代码进行修改，运维尽量减少对原有代码的修改，保持历史代码的纯洁性，提高系统的稳定性。在面向对象的设计中，所有的逻辑都是从原子逻辑组合而来的，而不是在一个类中独立实现一个业务逻辑。只有这样代码才可以复用，粒度越小，被复用的可能性就越大。

优势

1、开闭原则减轻测试压力

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

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

4、开闭原则符合面向对象开发的要求

食用方式

1、抽象约束

第一，通过接口或抽象类约束扩展，对扩展进行边界限定，不允许出现在接口或抽象类中不存在的public方法；

第二，参数类型、引用对象尽量使用接口或者抽象类，而不是实现类；

第三，抽象层尽量保持稳定，一旦确定即不允许修改。

2、 元数据（metadata）控制模块行为

@ 什么是元数据（metadata）控制模块行为？

先检查IP地址是否在允许访问的列表中，然后再决定是否需要到数据库中验证密码（如果采用SSH架构，则可以通过Struts的拦截器来实现），该行为就是一个。典型的元数据控制模块行为的例子，其中达到极致的就是控制反转。

3、制定项目章程

4、封装变化

@ 什么是封装变化 ？

也就是受保护的变化（protected variations），找出预计有变化或不稳定的点，我们为这些变化点创建稳定的接口，准确地讲是封装可能发生的变化，一旦预测到或“第六感”发觉有变化，就可以进行封装。

第一，将相同的变化封装到一个接口或抽象类中；

第二，将不同的变化封装到不同的接口或抽象类中，不应该有两个不同的变化出现在同一个接口或 抽象类中。

禅：

● Single Responsibility Principle：单一职责原则

● Open Closed Principle：开闭原则

● Liskov Substitution Principle：里氏替换原则

● Law of Demeter：迪米特法则

● Interface Segregation Principle：接口隔离原则

● Dependence Inversion Principle：依赖倒置原则