设计模式原则

最近重新回顾了下设计模式，这里归档总结下，方便以后可以看看。

设计模式总共有以下几个原则：

1、封装变化。

       找出应用中可能需要变化之处，把他们独立出来，不要和那些不需要变化的代码混在一起。

2、针对接口编程，而不是针对实现编程。

      假设有一个抽象类Animal，有两个具体的实现（Dog与Cat）继承Animal。

“针对实现编程”的做法：Dog d = new Dog();d.bark();

“针对接口编程”的做法：Animal animal = new Dog();animal.makeSound();

或者：Animal animal = getAnimal();animal.makeSound();

3、多用组合，少用继承。

• 继承会使类无限膨大，可能会使类变得臃肿。
• 子类可能会继承父类中那些无用甚至有害的方法。
• 组合比继承更灵活，可以实现在执行中动态改变对象的功能。

4、为了交互对象之间的松耦合设计而努力。

5、类应该对修改关闭，对扩展开放。

6、要依赖抽象，不要依赖具体类。
       不要让“高层组件”依赖“低层组件”，而且，不管“高层组件”还是“低层组件”，两者都应该依赖于抽象。避免违反该原则的几个方针：

• 变量不可以持有具体类的引用。 如果使用new，就会持有具体类的引用，可以使用工厂来避开这种引用。
• 不要让类派生自具体类。 如果派生自具体类，就会依赖具体类，可以派生自抽象或接口。
• 不要覆盖基类中已实现的方法。 如果覆盖基类中已实现的方法，那么基类就不是一个真正适合被继承的类。基类中已实现的方法应该被所有子类所共享。

7、最少知识原则。

      当你设计一个系统时，不管是任何对象，你都要注意与它交互的类有哪些，并注意它和这些类是如何交互的，尽量避免过多的类耦合在一起，带来维护成本的上升。就任何对象而言，在该对象的方法内，我们只应该调用以下范围的方法

• 该对象本身
• 被当作方法的参数而传递进来的对象
• 此方法所创建或实例化的任何对象
• 对象的任何组件。