面向对象设计原则

１. 迪米特法则（LoD）最少知识法则 

如果两个类不必彼此直接通信,那么这两个类就不应当发生直接的相互作用.如果其中一个类需要调用另一个类的某个方法的话,可以通过第三者转发这个调用. 

这个法则强调:在类的结构设计上,每一个类应当尽量降低成员的访问权限,尽量private,不需要让别的类知道的字段和行为就不要公开.它的根本思想是强调类之间的松耦合.因为类之间的耦合越弱,越有利于复用,一个处在弱耦合的类被修改,不会对关系的类造成波及.也可以说信息的隐藏能促进软件的复用. 

２. 依赖倒转原则 

＂抽象不应当依赖细节，细节应当依赖抽象＂，也就是针对接口编程而不是针对实现编程 

Ａ高层模块不依赖底层模块，两个都应该依赖抽象 

Ｂ抽象不依赖细节，细节应该依赖抽象 

在面向过程的开发过程中，为了使得代码可以复用，一般都会把这些常用代码写成许许多多的函数，然后调用这些底层函数就可以了．比如项目一般要访问数据库，所以把访问数据库的代码写成函数，每次做新项目时就去调用这些函数，这就是高层模块依赖底层模块． 

问题是，如果业务逻辑的高层模块都是一样的，但客户希望用不同的数据库或存储方式，我们希望能够复用这些高层模块，但高层模块都是与底层的访问数据库绑定在一起的，没办法复用这些高层模块，就非常糟糕了． 

就像计算机中的部件，如果ＣＰＵ，内存等依赖与主板,那么主板一坏,所有的部件都没有用了,再说部件也不能任意更换了. 

如果不管高层模块还是底层模块,它们都依赖与抽象,就是接口或抽象类,只要是接口稳定的,那么任何一个更改都不用担心会影响其它的,就是使得物理高层模块,还是底层模块,都可以很容易地被复用. 这就变成了依赖于抽象的接口或抽象类. 

在结合里氏代换原则,那就做活了. 

3. 里氏代换原则 

子类必须能够替换掉父类.因为只有当子类可以替换掉父类,软件单位的功能不受到影响时,父类才能真正被复用,而且子类也能够在父类的基础上增加新的行为. 

正是由于子类型的可替换性,才使得父类类型的模块在无需修改的情况下就可以扩展.不然还开放扩展,关闭修改呢.如下图所示 





依赖倒转原则是面向对象设计的标志,用哪种语言来编写程序并不重要,如果编写是考虑的都是如何针对抽象编程,即程序中所有的依赖关系都终止于抽象类或者接口,那么就是面向对象的设计,反之就是过程化的设计了. 

4. 开放封闭原则 

软件实体(类,模块,函数等)都是应该可以扩展的,但是不可修改. 即多扩展是开放的,但对于更改是封闭的. 

开发任何系统的时候,需求都是变化的,那么我们要面对需求的变化,进行软件的相应修改.但不能新的需求一来就要把整个程序推到重来. 

怎样的设计才能面对需求的改变保持相对稳定?从而使得系统可以在第一个版本以后就不断推出新的版本呢?开放-封闭原则就是答案. 

我们尽量在设计阶段,考虑到需求的种种变化,把问题想全了,就不会因为新需求一来就手足无措了,可是哪有那么容易!设计师不是未卜先知的神仙. 

开放封闭原则就是说在设计的时候尽量让这个类足够好,写好了就不要去更改了,如果新的需求来了,我们增加一些类就完了,原来的代码能不动就不动. 

绝对的对修改关闭是不可能的,因为无论模块多么封闭,都会存在一些无法对之封闭的变化.既然不可能完全封闭,设计人员就必须对他设计的模块应该对哪种变化封闭做出选择,他必须先猜测出最有可能发生的变化种类,然后构造抽象来隔离那些变化. 

实际中,还是很难预测变化的种类,那么没关系,我们在最初编写代码是,假设变化不会发生,但变化发生时,我们就创建抽象来隔离以后发生的同类变化,进行适时的重构.记住,我们希望的是在开发工作开展不久就知道可能发生的变化,查明可能变化的所等待的时间越长,要创建正确的抽象就越困难. 

开放-封闭原则是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处,就是可维护,可扩展,可复用,灵活性好.开饭人员应该仅对程序中呈现出频繁变化的那些部分做出抽象.然而也要注意,对应用程序的每个部分都刻意抽象同样不妙,拒绝不成熟的抽象和抽象本身一样重要. 

5. 单一职责原则 

就一个类而言,应该仅有一个引起它变化的原因. 

很多初级程序员在写程序的时候经常这么做:在一个Form类上,把各种各样的代码:业务逻辑,数据库访问的SQL语句一股脑添加到里面,维护麻烦,复用不可能. 

软件设计的一个重要工作就是发现职责并把这些职责相互分离,如果你想到多于一个的动机去改变一个类,那么这个类就具有多于一个的职责,就应该考虑职责分离了. 

最起码应当界面和算法和业务逻辑分离.如果一个类承担的职责过多,就等于把这些职责耦合在一起了,一个职责的变化可能就会削弱或抑制这个类完成其它职责的能力.这种耦合会导致脆弱的设计,当变化发生时,设计会遭到意想不到的,毁灭性的破坏.