很久没写文章了。最近看了些设计模式的书和文章，因此做一些笔记记录一下。
定义：就一个类而言，应该仅有一个引起它的变化的原因。通俗的说，一个类只负责一项职责。
原因：如果一个类承担的职责过多，就等于把这些职责耦合在一起，一个职责的变化可能会削弱或者抑制这个类完成其他职责的能力，这种耦合会导致脆弱的设计，当变化发生时，设计会遭受到意想不到的破坏。
例如，类A拥有P1、P2两项职责，当需求变更导致需要修改P1，就有可能让原本正常的P2职责发生故障。
优势:
- 类的复杂性降低，实现什么职责都有清晰明确的定义；
- 可读性提高，复杂性降低，那当然可读性提高了；
- 可维护性提高，可读性提高，那当然更容易维护了；
- 变更引起的风险降低，变更是必不可少的，如果接口的单一职责做得好，一个接口修改只对相应的实现类有影响，对其他的接口无影响，这对系统的扩展性、维护性都有非常大的帮助。
定义：软件实体应当对扩展开放，对修改关闭。通俗说，软件实体（类，模块、函数等等）应该可以扩展，但是不可修改。
总结：当软件需要变化时，我们应该尽量通过扩展的方式来实现变化，而不是通过修改已有的代码来实现。
定义：任何基类可以出现的地方，子类一定可以出现。通俗的说，一个软件实体如果使用的是一个父类，那么一定适用于其子类，而且它察觉不出父类对象和子类对象的区别。也就是说，子类能够替换父类被使用。
原因：需要在子类B拓展一个F2方法，方法F2需要用到父类A已实现的F1方法，假如在类B将F1方法重写，可能会导致F2方法没达到预期的结果。
因此：
- 子类可以实现父类的抽象方法，但不能覆盖父类的非抽象方法。
- 子类中可以增加自己特有的方法。
- 当子类的方法重载父类的方法时，方法的前置条件（即方法的形参）要比父类方法的输入参数更宽松。
- 当子类的方法实现父类的抽象方法时，方法的后置条件（即方法的返回值）要比父类更严格。
定义：客户端不应该依赖它不需要的接口；一个类对另一个类的依赖应该建立在最小的接口上。
原因，接口I1有3个方法声明F1、F2、F3，但是类A只需要实现F1、F2，为了保证程序正常编译，不得不去实现一个不做任何业务的F3方法。这样就导致接口臃肿，沉余代码过多。
因此，尽量细化接口，我们要为各个类建立专用的接口，而不要试图去建立一个很庞大的接口供所有依赖它的类去调用。
采用接口隔离原则对接口进行约束时，要注意以下几点：
- 接口尽量小，但是要有限度。但是如果过小，则会造成接口数量过多，使设计复杂化。
- 为依赖接口的类定制服务，只暴露给调用的类它需要的方法，它不需要的方法则隐藏起来。只有专注地为一个模块提供定制服务，才能建立最小的依赖关系。
- 提高内聚，减少对外交互。使接口用最少的方法去完成最多的事情。
定义：高层模块不应该依赖低层模块，二者都应该依赖其抽象；抽象不应该依赖细节；细节应该依赖抽象。抽象可以解释为抽象类和接口，细节解释为实现类。
原因：假如有类A原本是依赖类B，现在有需求改动，需要改为对类C的依赖，那么我们就得对类A进行调整，因此，我们对类A改动的时候，会对原有程序带来意外的风险。
因此，将类B、C相同的行为抽象为接口I1，而类A依赖成I1，那么类A可以通过接口I1间接与类B、C进行关联。从而减少对类A的修改，以后需求修改只要添加类D、E对接口I1的实现即可，降低类A与其他低层类之间的耦合，形成了面向接口编程，同时也满足了开闭原则。
传递依赖关系有三种方式:
接口传递、构造方法传递、setter方法传递
另外，
- 低层模块尽量都要有抽象类或接口，或者两者都有。
- 变量的声明类型尽量是抽象类或接口。
- 使用继承时遵循里氏替换原则。
PS:不得不承认，面向对象都是一些比较虚和抽象的东西，只有在不停编码的过程中去回忆和感悟，才能真正理解。一个项目不可能用各种各样的设计去满足以上的原则，不要为了设计而设计。。
参考《大话设计模式》和 系列文章 http://blog.csdn.net/zhengzhb/article/details/7278174