软件模式之原则设计

单一职责原则

　　一个类，只有一个引起它变化的原因。应该只有一个职责。每一个职责都是变化的一个轴线，如果一个类有一个以上的职责，这些职责就耦合在了一起。这会导致脆弱的设计。当一个职责发生变化时，可能会影响其它的职责。另外，多个职责耦合在一起，会影响复用性。例如：要实现逻辑和界面的分离。

　　什么是职责

　　SRP中，把职责定义为“变化的原因”。如果你能想到N个动机去改变一个类，那么这个类就具有多于一个的职责。这里说的“变化的原因”，只有实际发生时才有意义。可能预测到会有多个原因引起这个类的变化，但这仅仅是预测，并没有真的发生，这个类仍可看做具有单一职责，不需要分离职责。

 

开放-封闭原则

   是说软件实体应该可以扩展，但是不可以修改。对于扩展是开放的，对于更改是封闭的。

        软件实体应该是可扩展，而不可修改的。也就是说，对扩展是开放的，而对修改是封闭的。

　　因此，开放封闭原则主要体现在两个方面：

　　对扩展开放，意味着有新的需求或变化时，可以对现有代码进行扩展，以适应新的情况。

　　对修改封闭，意味着类一旦设计完成，就可以独立完成其工作，而不要对类进行任何修改。

　　“需求总是变化”、“世界上没有一个软件是不变的”，这些言论是对软件需求最经典的表白。从中透射出一个关键的意思就是，对于软件设计者来说，必须在不需要对原有的系统进行修改的情况下，实现灵活的系统扩展。而如何能做到这一点呢？

　　只有依赖于抽象。实现开放封闭的核心思想就是对抽象编程，而不对具体编程，因为抽象相对稳定。让类依赖于固定的抽象，所以对修改就是封闭的；而通过面向对象的继承和对多态机制，可以实现对抽象体的继承，通过覆写其方法来改变固有行为，实现新的扩展方法，所以对于扩展就是开放的。这是实施开放封闭原则的基本思路，同时这种机制是建立在两个基本的设计原则的基础上，这就是Liskov替换原则和合成/聚合复用原则。关于这两个原则，我们在本书的其他部分都有相应的论述，在应用反思部分将有深入的讨论。

　　对于违反这一原则的类，必须进行重构来改善，常用于实现的设计模式主要有Template Method模式和Strategy模式。而封装变化，是实现这一原则的重要手段，将经常发生变化的状态封装为一个类。

 依赖倒转原则

       抽象不应该依赖细节，细节应该依赖于抽象，说的直白一点就是面象接口编程，而不面象实现编程，可以参看Spring 框架的实现。

　    传递参数，或者在组合聚合关系中，尽量引用层次高的类。

　　主要是在构造对象时可以动态的创建各种具体对象，当然如果一些具体类比较稳定，就不必再弄一个抽象类做它的父类，这样有画蛇添足的感觉。

　　优点：

　　系统扩展灵活。

　　缺点：

　　需要大量的类。

 

 里氏代换原则

    一个软件实体如果使用一个父类的话，那么一定适于其他的子类，而且它察觉不出父类对象和子类对象的区别。也就是说，在软件里面，把父类都替换成的它子类，程序没有变化。