设计模式--设计原则

设计原则1: 把问题归零
封装变化

如果每次新的需求一来，都会使某方面的代码发生变化， 那么你就可以确定，这部分的代码需要被抽出来， 和其他稳定的代码有所区分。

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

把会变化的部分取出来并封装起来, 以便以后可以轻易地改动或扩充此部分, 而不影响不需要变化的其他部分, 这使得系统变得更有弹性

例如一个超类中同时有一些不变的部分和一些变化的部分, 那么此时应将变化的部分从超类中取出进行单独的抽象, 这样做的好处是即使以后修改了变化的部分, 也不会对派生类产生任何的影响

设计原则2: 希望一切能有弹性

针对接口编程, 而不是针对实现编程

"针对接口编程"真正的意思是"针对超类型(supertype)编程"， 针对接口编程， 关键就在多态。利用多态， 程序可以针对超类型编程，执行时会根据实际状况执行到真正的行为，不会被绑死在超类型的行为上。”针对超类型编程“这句话， 可以更明确的地说成”变量的声明类型应该是超类型，通常是一个抽象类或者是一个接口， 如此，只要是具体实现此超类型的类所产生的对象， 都可以指定给这个变量。 这也意味着， 声明类时不用理会以后执行时的真正对象类型！

变量的声明类型应该是抽象类或一个接口, 运行时不用知道执行时真正的对象到底是什么类型

设计原则3: “有一个”可能比“是一个”更好

多用组合, 少用继承

使用组合建立系统具有更大的弹性，不仅可以将算法族封装成类，更可以在”运行时动态的改变行为”

1~3 代表模式:  策略模式

虽然借由继承， 好东西可以一再被利用， 所以程序开发时间就会大幅减少， 但是软件开发完成”后“比完成”前“总是要花费更多的时间， 即我们总是需要花许多时间在系统的维护和变化上， 比原先开发的时间更多，因此我们应该致力于提高可维护性和可扩展性上的复用程度

设计原则4:  松耦合-降低依赖

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

代表模式: 观察者模式

当两个对象之间松耦合， 它们依然可以交互，但是不太清楚彼此的细节。

观察者模式提供了一种对象设计， 让主题和观察者之间松耦合。

松耦合的设计之所以能让我们建立有弹性的OO系统， 能够应对变化， 是因为对象之间的互相依赖降到了最低。

即， 当我们改变系统中的其中一方时，不会影响另一方， 任何一方都可以独立复用

设计原则5: 开放-关闭原则

类应该对扩展开放, 对修改关闭

代表模式: 装饰者模式

允许类容易扩展， 在不修改现有代码的情况下， 就可搭配新的行为。

实现这样的目标有什么好处？

这样的设计具有弹性可以应对改变， 可以接受新的功能来应该改变的需求。

设计原则6： 依赖倒置原则

要依赖抽象，不要依赖具体类

代表模式： 工厂方法模式

这个原则听起来很像“针对接口编程， 不针对实现编程”， 然而这里更强调抽象， 这个原则说明了：

不能让高层组件依赖低层组件， 而且， 不管高层或低层组件， 两者都应该依赖于抽象。

设计原则7：最少知识原则

只和你的密友谈话

代表模式：外观模式

这个原则是说，当你正在设计一个系统，不管是任何对象，你都要注意它所交互的类有哪些，并注意它和这些类是如何交互的。

这个原则希望我们在设计中，不要让太多的类耦合在一起，免得修改系统中一部分，会影响到其他部分。如果许多类之间互相依赖，那么这个系统就会变成一个易碎的系统，它需要花许多成本维护，也会因为太复杂而不容易被其他人了解。

设计原则8：好莱坞原则

别调用（打电话给）我们，我们会调用（打电话给）你

代表模式：模板方法模式

好莱坞原则可以给我们一种防止“依赖腐败”的方法。当高层组件依赖低层组件，而低层组件又依赖高层组件，而高层组件又依赖边侧组件，而边侧组件又依赖低层组件时，依赖腐败就发生了。在这种情况下，没有人可以轻易地搞懂系统是如何设计的。

在好莱坞原则之下，我们允许低层组件将自己挂钩到系统上，但是高层组件会决定什么时候和怎样使用这些低层组件。换句话说，高层组件对待低层组件的方法是“别调用我们，我们会调用你”。

设计原则9 : 单一责任原则

一个类应该只有一个引起变化的原因

代表模式: 迭代器模式

我们知道要避免类内的改变,因为修改代码很容易造成许多潜在的错误.如果有一个类具有两个改变的原因,那么这会使得将来该类的变化几率上升,而当它真的改变时,你的设计中同时有两个方面将会受到影响. 要如何解决呢? 这个原则告诉我们将一个责任只指派给一个类.

这听起来容易,但其实做起来并不简单:区分设计中的责任,是最困难的事情之一.我们的大脑很习惯看着一大群行为,然后将他们集中在一起,尽管他们可能属于两个或多个不同的责任.想要成功的唯一方法,就是努力不懈地检查你的设计,随着系统的成长,随时观察有没有迹象显示某个类改变的原因超出一个.

应该如何遵守设计原则？

所有的原则都应该在有帮助的时候才遵守。所有的设计都不免需要折衷（在抽象和速度之间取舍，在空间和时间之间平衡……）。虽然原则提供了方针，但在采用原则之前，必须全盘考虑所有的因素。