设计模式思想(一)

原文章来源：http://blog.csdn.net/xutao_ustc/article/details/6328533

1、单一职责：就一个类而言，应该仅有一个引起它变化的原因。职责要单一。否则如果一个代码块完成了超过一件的事情，意味着这段代码的移植性受到了影响，因为一次移植就打包移动了两段逻辑。而且不稳定，因为可能任何一个需要改动都会动这段代码块。软件设计真正要做的许多内容，就是发现职责并把那些职责相互分离。如果你能想到多于一个的动机去改变一个类，那么这个类就有多于一个的职责，应相互分离。

 

2、开闭原则：软件实体应当对扩展开放，对修改关闭。软件系统中包含的各种组件，例如模块（Modules）、类（Classes）以及功能（Functions）等等，应该在不修改现有代码的基础上，引入 新功能。开闭原则中“开”，是指对于组件功能的扩展是开放的，是允许对其进行功能扩展的；开闭原则中“闭”，是指对于原有代码的修改是封闭的，即不应该修改原有的代码。 实现开闭原则的关键就在于“抽象”，无论怎么设计，当然会有一些无法预见到得情况，所以要充分了解需求，猜到以后可能会有的变化，然后构造抽象隔离变化。我们很难事先猜测，但我们可以在发生小变化时，隔离同类变化，并及早做抽象，并想办法应付更大变化的可能。有变化就立刻行动。

 

3、依赖倒转：高层模块不应该依赖低层模块，应该依赖于抽象。倘若我们设计了一个低层模块，并在高层模块调用这个模块，那么高层中就和这个模块绑定在了一起，倘若我们的低层要换成另一种实现，那么上层的实现是和低层绑定在一起的，就废掉了。就好像我们的电脑上的主板只能兼容一种牌子的显卡。如果我们的显卡申明了我能兼容任何实现了这种标准的显卡，那么厂家就可以按照这个标准实现，那么主板就可以兼容多个牌子的显卡了。软件设计应该依赖于抽象，具体的说就是抽象类，只要接口是稳定的，那么任何一个的更改都不用担心其他的部分受到影响。里氏替换：就是说子类必须完全在功能上覆盖父类，能用父类的地方，一定要可以使用子类，察觉不出差别，否则不能作为子类。例如，父类鸟有飞的功能，尽管在生物界企鹅是一种鸟，但是在编程建模里面，就不能把企鹅作为鸟的一种。

 

4.迪米特法则--又叫最少知识原则（Least Knowledge Principle, LKP）。迪米特法则可以简单说成：talk only to your immediate friends。  对于面向OOD来说，又被解释为下面几种方式：
一个软件实体应当尽可能少的与其他实体发生相互作用。
每一个软件单位对其他的单位都只有最少的知识，而且局限于那些与本单位密切相关的软件单位。

迪米特法则的初衷在于降低类之间的耦合。由于每个类尽量减少对其他类的依赖，因此，很容易使得系统的功能模块功能独立，相互之间不存在（或很少有）依赖关系。

迪米特法则不希望类直接建立直接的接触。如果真的有需要建立联系，也希望能通过它的友元类来转达。因此，应用迪米特法则有可能造成的一个后果就是：系统中存在大量的中介类，这些类之所以存在完全是为了传递类之间的相互调用关系——这在一定程度上增加了系统的复杂度

有兴趣可以研究一下设计模式的门面模式（Facade）和中介模式（Mediator），都是迪米特法则应用的例子。