注册
登录

您现在的位置是:首页 > 学无止境

OO设计模式和设计原则

木木彡82 2008-08-20 14:29:00 470人围观
OO设计模式和设计原则 1.1 设计正在“腐烂”的征兆(Symptoms of Rotting Design)    有四个主要的征兆告诉我们该软件设计正在“腐烂”中。它们并不是互相独立的,而是互相关联,它们是过于僵硬、过于脆弱、不可重用性和粘滞性过高。    1. 过于僵硬Rigidity Ri...
OO设计模式和设计原则
 

1.1 设计正在“腐烂”的征兆(Symptoms of Rotting Design)

    有四个主要的征兆告诉我们该软件设计正在“腐烂”中。它们并不是互相独立的,而是互相关联,它们是过于僵硬、过于脆弱、不可重用性和粘滞性过高。

    1. 过于僵硬Rigidity Rigidity 致使软件难以更改,每一个改动都会造成一连串的互相依靠的模块的改动,项目经理不敢改动,因为他永远也不知道一个改动何时才能完成。

    2. 过于脆弱Fragility Fragility 致使当软件改动时,系统会在许多地方出错。并且错误经常会发生在概念上与改动的地方没有联系的模块中。这样的软件无法维护,每一次维护都使软件变得更加难以维护。(恶性循环)

    3. 不可重用性immobility immobility 致使我们不能重用在其它项目中、或本项目中其它位置中的软件。工程师发现将他想重用的部分分离出来的工作量和风险太大,足以抵消他重用的积极性,因此软件用重写代替了重用。

    4. 粘滞性过高viscosity viscosity有两种形式:设计的viscosity和环境的viscosity.当需要进行改动时,工程师通常发现有不止一个方法可以达到目的。但是这些方法中,一些会保留原有的设计不变,而另外一些则不会(也就是说,这些人是hacks)。一个设计如果使工程师作错比作对容易得多,那么这个设计的viscosity 就会很高。

    环境的viscosity高是指开发环境速度很慢且效率很低。

    2 面向对象的类设计原则

    2.1 开放关闭原则The Open Closed Principle (OCP)

    A module should be open for extension but closed for modification.一个模块应该只在扩展的时候被打开(暴露模块内部),在修改的时候是关闭的(模块是黑盒子)。

    在所有的面向对象设计原则中,这一条最重要。该原则是说:我们应该能够不用修改模块的源代码,就能更改模块的行为。

    2.1.1 动态多态性(Dynamic Polymorphism)

    2.1.2 静态多态性(Static Polymorphism)

    另外一种使用OCP的技术就是使用模板或范型,如Listing 2-3.LogOn函数不用修改代码就可以扩展出多种类型的modem. 2.1.3 OCP的体系结构目标(Architectural Goals of the OCP)

    通过遵照OCP应用这些技术,我们能创建不用更改内部代码就可以被扩展的模块。这就是说,在将来我们给模块增添新功能是,只要增加新的代码,而不用更改原先的代码。 使软件完全符合OCP可能是很难的,但即使只是部分符合OCP,整个软件的结构性能也会有很大的提高。我们应该记住,让变化不要波及已经正常工作的代码总是好的。

    2.2 Liskov 替换原则The Liskov Substitution Principle(LSP)

    Subclasses should be substitutable for their base classes.子类应该可以替换其基类。

    如下图2-14所示。Derived类应该能替换其Base类。也就是说,Base基类的一个用户User如果被传递给一个Devrived类而不是Base类作为参数,也能正常的工作。

    2.3 依赖性倒置原则The Dependency Inversion Principle (DIP)1

     Depend upon Abstractions. Do not depend upon concretions.依赖抽象,不要依赖具体。

    如果说OCP声明了OO体系结构的目的,DIP则阐述了其主要机制。依赖性倒置的策略就是要依赖接口、或抽象函数、或抽象类,而不是依赖于具体的函数和类。这条原则就是支持组件设计、COM、CORBA、EJB等等的背后力量。

    2.3.1 依赖抽象Depending upon Abstractions.

    实现该原则十分简单。设计中的每一个依赖都应该是接口、抽象类,不要依赖任何一个具体类。

    显然这样的限制比较严峻,但是我们应该尽可能的遵守这条原则。原因很简单,具体的模块变化太多,抽象的则变化少得多。而且,抽象是“铰链”点,在这些位置,设计可以弯曲或者扩展,而不用进行更改(OCP)。

    2.4 接口隔离原则The Interface Segregation Principle (ISP)

    ‘Many client specific interfaces are better than one general purpose interface多个和客户相关的接口要好于一个通用接口。

    ISP是另一条在底层支持组件如COM技术的原则。没有它,组件和类的易用性和重用性都会大打折扣。该原则的实质很简单:如果一个类有几个使用者,与其让这个类载入所有使用者需要使用的所有方法,还不如为每一个使用者创建一个特定的接口,并让该类分别实现这些接口。

    3 包体系结构的原则Principles of Package Architecture

    类是必不可少的,但对于组织一个设计来说还不够,粒度更大的包有助于此。但是我们应该怎样协调类和包之间的从属关系?下面的三条原则都属于包聚合原则,能对我们有所帮助。

    3.1 包聚合原则

    3.1.1 发布重用等价原则The Release Reuse Equivalency Principle (REP)1

    重用的粒度就是发布的粒度。The granule of reuse is the granule of release.一个可重用的元件(组件、一个类、一组类等),只有在它们被某种发布(Release)系统管理以后,才能被重用。用户不愿意使用那些每次改动以后都要被强迫升级的元件。因此,即使开发者发布了可重用元件的新版本,他也必须支持和维护旧版本,这样才有时间让用户熟悉新版本。

    因此,将什么类放在一个包中的判断标准之一就是重用,并且因为包是发布的最小单元,它们同样也是重用的最小单元。体系结构师应该将可重用的类都放在包中。

    3.1.2 共同封闭原则The Common Closure Principle (CCP)2

   一起变化的类放在一起。Classes that change together, belong together.一个大的开发项目通常分割成很多网状互联的包。管理、测试和发布这些包的工作可不是微不足道的工作。在任何一个发布的版本中,如果改动的包数量越多,重建、测试和部署也就会越多。因此我们应该尽量减少在产品的发布周期中被改动的包的数量,这就要求我们将一起变化的类放在一起(同一个包)。

    3.1.3 共同重用原则The Common Reuse Principle (CRP)3

    不一起重用的类不应该放在一起。Classes that aren‘t reused together should not be grouped together.对一个包的依赖就是对包里面所有东西的依赖。当一个包改变时,这个包的所有使用者都必须验证是否还能正常运行,即使它们所用到的没有任何改变也不行。

    比如我们就经常遇到操作系统需要升级。当开发商发布一个新版本以后,我们的升级是迟早的问题,因为开发商将会不支持旧版本,即使我们对新版本没有任何兴趣,我们也得升级。

    如果把不一起使用的类放在一起,同样的事情我们也会遇到。一个和我们无关的类的改变也产生包的一个新版本,我们被强迫升级和验证这个包是否影响正常的运行。

    3.1.4 包聚合原则之间的张力Tension between the Package Cohesion Principles

    这三条原则实际上是互斥的。它们不能被同时满足,因为每一条原则都只针对某一方面,只对某一部分人有好处。REP和CRP都想重用元件的人有好处,CCP对维护人员有好处。CCP使得包有尽可能大的趋势(毕竟,如果所有的类都属于一个包,那么将只会有一个包变化);CRP尽量使得包更小。

    幸运的是,包并不是一成不变的。实际上,在开发过程中,包的转义和增删都是很正常的。在项目开发的早期,软件建筑师建立包的结构体系,此时CCP占主导地位,维护只是辅助。在体系结构稳定以后,软件建筑师会对包结构进行重构,此时尽可能的运用REP和CRP,从而最大的方便重用元件的人员。

    3.2 包耦合原则The Package Coupling Principles.

   下面三条原则主要关心包之间的关系。

    3.2.1 无依赖回路原则The Acyclic Dependencies Principle (ADP)1

    包与包之间的依赖不能形成回路。The dependencies between packages must not form cycles.因为包是发布的粒度。人们倾向于节省人力资源,所以工程师们通常只编写一个包而不是十几个包。这种倾向由于包聚合原则被放大,后来人们就将相关的类组成一组。

    因此,工程师发现他们只会改动较少的几个包,一旦这些改动完成,他们就可以发布他们改动的包。但是在发布前,他们必须进行测试。为了测试,他们必须编译和连编他们的包所依赖的所有的包。

    3.2.2 依赖稳定原则(Stable Dependencies Principle,SDP)

    朝稳定的方向依赖Depend in the direction of stability.虽然这条原则看起来很明显,但是关于这方面还是有很多需要说明的地方,稳定性并不一定为大家所了解。

    稳定性是什么?站在一个硬币上,这稳定吗?很可能你说不。然而,除非被打扰,硬币将保持那个位置很长时间。硬币没有变化,但是很难认为它是稳定的。稳定性与需要改动所要做的工作量相关。硬币不稳定是因为只需要很小的工作量就能把它翻过来。换个角度,桌子就要稳定得多。

    对于软件这说明什么?一个软件包很难被改动受很多因素影响:代码大小、复杂度、透明度等等。这些我们先不说,可以肯定的一点是,如果有很多其它的包依赖于一个软件包,那么该软件包就难以改动。一个包如果被许多其它包依赖,那么该包是很稳定的,因为这个包的任何一个改动都可能需要改动很多其它的包。

    3.2.3 稳定抽象原则( Stable Abstractions Principle ,SAP)

    稳定的包应该是抽象包。Stable packages should be abstract packages.我们可以想象应用程序的包结构应该是一个互相联系的包的集合,其中不稳定的包在顶端,稳定的包在底部,所有的依赖方向朝下。那些顶端的包是不稳定而且灵活的,但那些底部的包就很难改动。这就导致一个两难局面:我们想要将包设计为难以改动的吗?

    明显地,难以改动的包越多,我们整个软件设计的灵活性就越差。但是好像有一点希望解决这个问题,位于依赖网络最底部的高稳定性的包的确难以改动,但是如果遵从OCP,这样的包并不难以扩展。

文章评论

  • 登录后评论

点击排行