OOD的五个原则:

OOD的五个原则:

(一):SRP,单一职责原则(只有佛自己应当担负起公布玄妙秘密的职责...)

一个类应该只有一个发生变化的原因.

因为每一个职责都是变化的一个轴线,当需求变化时,该变化会反映为类的职责的变化.如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个.如果一个类承担的职责过多,就等于把这些职责耦合在了一起.

注意:仅当变化发生时,变化的轴线才具有实际意义;如果没有征兆,那么应用SPR或者其它任何原则都是不明智的.

(二):OCP,开放-封闭原则(两截门,一个被水平分割为两部分的门,这样每一部分都可以独立保持开放或者封闭)

软件实体(类,模块,函数等)应该是可以扩展的,但是不可修改.

OCP的两个主要特征:

(1):对于扩展是开放的(open for extension):意味着模块的行为是可以扩展的,当应用的需求改变时,我们可以对模块进行扩展,使其具有满足那些改变的新行为,换句话说,我们可以改变模块的功能.

(2):对于修改是关闭的(closed for modification):对模块行为进行扩展时,不必改动模块的源代码或者二进制代码,无论是可链接的库,DLL或者EXE文件,都不必修改.

那如何去实现呢,答案就是抽象.由于模块依赖于抽象,所以它对于更改可以是封闭的,同时,通过从这个抽象体派生,可以扩展此模块的行为.

在此常用的两个设计模式是:STRATEGY模式跟TEMPLATE METHOD模式.

其实是不可能做到完全封闭,那么就必须有策略地对待这个问题,也就是说,设计人员必须对于他设计的模块应该对哪种变化封闭做出选择,他必须先猜测出最有可能发生的变化种类,然后构造抽象来进行隔离.

结论:OCP是面向对象设计的核心所在,遵循这个原则可以带来面向对象技术所声称的巨大好处:灵活性,可重用性以及可维护性.对于应用程序中的每个部分都肆意地进行抽象同样不是一个好主意.正确的做法是:设计人员应该仅仅对程序中呈现出频繁变化的那些部分做抽象.

(三):LSP,里氏替换原则

子类型(subtype)必须能够替换掉它们的基类型(base type).

Barbara Liskov首次写下这个原则是在1988年,她说道:若对类型S的每一个对象O1,都存在一个类型T的对象O2,使得在所有针对T编写的程序P中,用O1替换O2后,程序P的行为功能不变,则S就是T的子类型.

LSP清楚地指出,OOD中的IS-A关系是就行为方式而言的,而行为方式是可以进行合理假定的,是客户程序依赖的.从此可以看出:很多东西可能表面上是IS-A,但其实并不是.

基于契约式设计(Design By Contract DBC),可以很好地支持LSP.

(四):DIP,依赖倒置原则(绝不能让国家的重大利益依赖于那些会动摇人类薄弱意志的众多可能性)

DIP的两个主要原则:

(1):高层模块不应该依赖于低层模块,二者都应该依赖于抽象;

(2):抽象不应该依赖于细节,细节应该依赖于抽象;

Booch曾经说过:"所有结构良好的面向对象构架都具有清晰的层次定义,每个层次通过一个定义良好的,受控的接口向外提供了一组内聚的服务."其实每个较高层次都为它所需要的服务声明一个抽象接口,较低的层次实现这些抽象接口.每个高层类都通过该抽象接口使用下一层,这样高层就不依赖于低层,低层反而依赖于高层中声明的抽象服务接口.

这里的倒置不仅仅是依赖关系的倒置,它也是接口所有权的倒置,我们通常会认为工具库拥有它们自己的接口.但是当应用了DIP时,我们发现往往是客户拥有抽象接口,而它们的服务者则从这些抽象接口派生.这也就是著名的Hollywood原则:"Don't call us,we'll call you.(不要调用我们,我们会调用你)".

依赖于抽象,这是一个简单的陈述,该启发规则建议不应该依赖于具体类,也就是说,程序中所有的依赖关系都应该终止于抽象或者接口.它提醒我们应该这样来编码:a,任何变量都不该持有一个指向具体类的引用;b,任何类都不该从具体类派生;c,任何方法都不该重写它的任何基类中已经实现了的方法.

(五):ISP,接口隔离原则

胖类会导致它们的客户程序之间产生不正常的并且有害的耦合关系,当一个客户程序要求该胖类进行一个改动时,会影响到所有其它的客户程序.因此,客户程序应该仅仅依赖于它们实际调用的方法.通过把胖类的接口分解为多个特定于客户程序的接口,可以实现这个目标.每个特定于客户程序的接口仅仅声明它的特定客户或客户组调用的那些函数,接着,该胖类就可以继承所有特定于客户程序的接口,并实现它们.这就解除了客户程序和它们没有调用的方法间的依赖关系,并使客户程序间互不依赖.