中级软件设计考试总结

1.排序：

排序方最好时间平均时间最坏时间辅助空稳定性原序列有否监

法复杂度复杂度复杂度间是否有视哨

序

直接插0(n)0(n2)0(n2)0(1)稳定性有序可有可

入排序无

冒泡排0(n)0(n2)0(n2)0(1)稳定性不知道没有

序

简单选0(n)0(n2)0(n2)0(1)不稳定不知道没有

择排序

希尔排-0(n13)—0(1)不稳定不知道没有

序“缩小

增量排

序”

2

快速排O(nlog2n)O(nlog2n)0(n)o(log2n)不稳定不知道有

序

堆排序O(nlogn)O(nlogn)不稳定不知道没有

O(nlog2n)220(1)

归并排O(nlogn)O(nlogn)0(n)稳定不知道没有

O(nlog2n)22

序

基数排O(d(n+r*d))O(d(n+r*d))O(d(n+r*d))O(rd)稳定不知道没有

序

2.段页式存储管理：

段号S段内页号p页内地址W

3.页面转换算法：①最佳转换算法：命中率是最好।，但是很难实现，理论行。还有一个就是

缺页中断次数，②先进先出转换算法：性能最差的算法。③最近最少未使用转换算法：④最

近未未用转换算法：

4.磁盘调度算法：①先来先服务(FCFS)：有一个平均寻道长度，平均寻道时间，这是这个问

题的关键。②最短寻道时间优先(SSTF)③扫描算法(SCAN)④单向扫描调度算法(CSCAN):

单向进行移动，不进行等待，一开始从里向外扫描完之后，然后再从外回到里后，再进行从

里向外进行扫描，它只能进行单向的扫描。

5.利用Gantt图可以进行软件的进度管理，进度的管理同样可以用项目计划评审技术

(ProgamEvaluation&ReviewTechnique,PERT),也就是软件的不同的任务所用的时间。

最终完成的时间,Gantt图同样可以进行设备利用率的计算,PERT图有最早时间和最迟时间，

是一个图，也就是图中有关键路径，最早时刻和最迟时刻

6.程序设计基本模块：

控制模块

基本程序模块图

7.P操作与V操作的实现方式：P操作一开始是用信号量S=l,而且是P操作的作用是申请资

源，即资源数是减1，S-1,而V操作就是信号量s=o,v操作的作用是释放资源，也就是资源

加1.

P操作与V操作的所有说明，详细说明

8.跨两个页面就是占用两个的页内地址。一个页就产生一次的缺页中断，如果取出指令分析

是多字节的，那么系统将产生一次缺页中断取指令的后半部分。

9.极限编程（eXtremeProgamming）原则:交流，简单,反馈和勇气

10.CMM成熟度的测试：有四个等级：初始级（1级），可重复级（2级），定义级（3级），

管理级（4级），优化级（5级）

11.多部件系统可靠性衡量方法：

两个数据处理部件采用并联结构，该部分的可靠性为1-（1-0.6）*（1-0.6）=0.84.设数据存

储部分可靠性为R,则整个系统的可靠性为：0.84*R>=0.66,所以R>=0.66/0.84比0.79

12.类库与框架的作用和区别：类库为应用程序提供了一组可以被使用的类，而框架除了提

供类之外，还基本实现了•个可以执行的架构。

13.软件设计模式：

①外观设计模式:设计模式一外观模式Facade（结构型）:

1.概述

外观模式,我们通过外观的包装，使应用程序只能看到外观对象，而不会看到具体的

细节对象，这样无疑会降低应用程序的复杂度，并且提高了程序的可维护性。

例子1：一个电源总开关可以控制四盏灯、一个风扇、一台空调和一台电视机的启动和关闭。

该电源总开关可以同时控制述所有电器设备，电源总开关即为该系统的外观模式设计。

2.问题

为了降低复杂性，常常将系统划分为若干个子系统。但是如何做到各个系统之间的通信和相

互依赖关系达到最小呢？

3.解决方案

外观模式:为子系统中的一组接口提供一个一致的界面，Facade模式定义了个高层接

口，这个接口使得这一子系统更加容易使用。引入外观角色之后，用户只需要直接与外观角

色交互，用户与子系统之间的复杂关系由外观角色来实现，从而降低了系统的耦合度。

外观设计模式的例子

适用性

在遇到以下情况使用facade模式:

1）当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来

越复杂。大多数模式使用时都会产生更多更小的类。

这使得子系统更具可重用性，也更容易对子系统进行定制，但这也给那些不需要定制子

系统的用户带来一些使用上的困难。facade可以提供一个简单的缺省视图，

这一视图对大多数用户来说已经足够，而那些需要更多的可定制性的用户可以越过

facade层。

2）客户程序与抽象类的实现部分之间存在着很大的依赖性。引入facade将这个子系统

与客户以及其他的子系统分离，可以提高子系统的独立性和可移植性。

3）当你需要构建一个层次结构的子系统时，使用facade模式定义子系统中每层的入口

点。如果子系统之间是相互依赖的，你可以让它们仅通过facade进行通讯，从而简化了它

们之间的依赖关系。

结构

6.构建模式的组成

外观角色（Facade）：是模式的核心，他被客户client角色调用，知道各个子系统的功能。

同时根据客户角色已有的需求预订了几种功能组合'

子系统角色（Subsystemclasses）：实现子系统的功能，并处理由Facade对象指派的任

务。对子系统而言，facade和client角色是未知的，没有Facade的任何相关信息；即没有

指向Facade的实例。

客户角色（client）：调用facade角色获得完成相应的功能。

效果

Facade模式有下面一些优点：

1）对客户屏蔽子系统组件，减少了客户处理的对象数目并使得子系统使用起来更加容易。

通过引入外观模式，客户代码将变得很简单，与之关联的对象也很少。

2）实现了子系统与客户之间的松耦合关系，这使得子系统的组件变化不会影响到调用它的

客户类，只需要调整外观类即可。

3）降低了大型软件系统中的编译依赖性，并简化了系统在不同平台之间的移植过程，因为

编译一个子系统一般不需要编译所有其他的子系统。一个子系统的修改对其他子系统没有任

何影响，而且子系统内部变化也不会影响到外观对象。

4）只是提供了一个访问子系统的统•入口，并不影响用户直接使用子系统类。

Facade模式的缺点

1）不能很好地限制客户使用子系统类，如果对客户访问子系统类做太多的限制则减少了可

变性和灵活性。

2）在不引入抽象外观类的情况下，增加新的子系统可能需要修改外观类或客户端的源代码,

违背了“开闭原则”。

实现

我们使用开关的例子;

1<?php

2/**

3*外观模式

4*

5*

6classSwitchFacade

7

8.private$_light=null;

9.private$_ac=null;

10.private$_fan=null;

11.private$_tv=null;

12.

13.publicfunction_construct()

14.{

15.$this->_light=newLight();

16.$this->_fan=newFan();

17.$this->_ac=newAirConditioner();

18.$this->_tv=newTelevision。；

19.}

20./**

21.*晚上开电灯

22.*

23.*/

24.publicfunctionmethodl($isOpen=1){

25.if($isOpen==1){

26.$this->_light->on();

27.$this->_fan->on();

28.$this->_ac->on();

29.$this->_tv->on();

30.}else(

31.$this->_light->off();

32.$this->_fan->off();

33.$this->_ac->off();

34.$this->_tv->off();

35.)

36.

37.}

38,/**

39.*i

40.*

41.*/

42.publicfunctionmethod2(){

43.if($isOpen==1){

44.$this->_fan->on();

45.$this->_ac->on();

46.$this->_tv->on();

47.}else{

48.$this->_fan->off();

49.$this->_ac->off();

50.$this->_tv->off();

51.)

52.}

53.}

54.

55./******************************************子系统类************/

56,/**

57.*

58.*/

59.classLight

60.{

61.private$_isOpen=0;

62.publicfunctionon(){

63.echo*Lightisopen*,1<br/>';

64.$this->_isOpen=1;

65.}

66.publicfunctionoff(){

67.echo'Lightisoff','<br/>1;

68.$this->_isOpen=0;

69.}

70.}

71.

72.classFan

73.(

74.private$_isOpen=0;

75.publicfunctionon(){

76.echo'Fanisopen',1<br/>';

77.$this->_isOpen=1;

78.}

79.publicfunctionoff(){

80.echo'Fanisoff',1<br/>';

81.$this->_isOpen=0;

82.}

83.}

84.

85.classAirConditioner

86.{

87.private$_isOpen=0;

88.publicfunctionon(){

89.echo'AirConditionerisopen','<br/>';

90.$this->_isOpen=1;

91.}

92.publicfunctionoff(){

93.echo'AirConditionerisoff','<br/>';

94.$this->_isOpen=0;

95.}

96.}

97.classTelevision

98.{

99.private$_isOpen=0;

100.publicfunctionon(){

101.echo'Televisionisopen','<br/>';

102.$this->__isOpen=1;

103.}

104.publicfunctionoff(){

105.echo'Televisionisoff','<br/>';

106.$this->__isOpen=0;

107.}

108.}

109./*♦

110.*客户类

111.*

112.*/

113.classclient{

114.staticfunctionopen(){

115.$f=newSwitchFacade();

116.$f->methodl(l);

117.}

118.

119.staticfunctionclose(){

120.$f=newSwitchFacade();

121.$f->methodl(0);

122.}

123.}

124.client::open();

14.Singleton(单件)设计模式：单例设计模式：单态设计模式：

这个模式似乎没有产生新的设计原则，不过还是回顾以下吧:

1.封装变化

2.多用组合，少用继承

3.针对接口编程，不针对实现编程

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

5.类应该扩展开放，对修改关闭

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

单例模式一确保一个类只有一个实例，并提供全局访问点0

要点:

单件模式确保程序中一个类最多只有一个实例。

单件模式也提供访问这个实例的全局点。

在Java中实现单件模式需要私有的构造器、一个静态方法和一个

静态变量。

确定在性能和资源上的限制，然后小心地选择适当的方案来实现

单件，以解决多线程问题(我们必须认定所有的程序都是多线程

的)。

如果不采用第5版的Java2双重检查加锁实现会失效。

小心，你如果使用多个类加载器，可能导致单件失效而产生多个

实例o

如果使用JW1.2或之前的版本，你必须简历单件注册表，以免

垃圾收集器将单件回收。

packagesingleTonPattern;

/**

*2013/6/6

*

*©authorwwj单例模式

*/

publicclassSingleton{

//利用•个静态变量来记录Singleton类的唯•实例

privatestaticSingletonuniqueinstance;

//把构造器声明为私有的，只有自Singleton类内才可以调用构造器

privateSingleton(){};

*用这个方法实例化对象，并返回这个实例

*@return

publicstaticSingletongetlnstance(){

if(uniqueinstance==null){

uniqueinstance=newSingleton();

)

returnuniqueinstance;

*使用同步的方法，解决多线程灾难

*但这种方法会影响程序执行效率

*@return

*//*

publicstaticsynchronizedSingletongetlnstance(){

if(uniqueinstance==null){

uniqueinstance=newSingleton();

}

returnuniqueinstance;

)*/

*使用“急切”创建实例，而不用延迟实例化的做法

*privatestaticSingletonuniqueinstance=newSingleton();

publicstaticSingletongetlnstance(){

returnuniqueinstance;

)*/

*用"双重检查加锁“，在getlnstance。中减少使用同步

*如果性能是你关心的重点，这种做法可以帮你大大减少get工nstance()的时间耗费

/♦privatevolatilestaticSingletonuniqueinstance;

publicstaticSingletongetlnstance(){

if(uniqueinstance==null){

synchronized(Singleton.class){

if(uniqueinstance==null){

uniqueinstance=newSingleton;

}

}

}

}*/

)

设计模式（八）装饰器模式Decorator（结构型）

1.概述

若你从事过面向对象开发，实现给一个类或对象增加行为，使用继承机制，这是所有

面向对象语言的一个基本特性。如果已经存在的一个类缺少某些方法，或者须要给方法添加

更多的功能（魅力），你也许会仅仅继承这个类来产生一个新类一这建立在额外的代码上。

通过继承一个现有类可以使得子类在拥有自身方法的同时还拥有父类的方法。但是这

种方法是静态的，用户不能控制增加行为的方式和时机。如果你希望改变•个已经初始化

的对象的行为，你怎么办？或者，你希望继承许多类的行为，改怎么办?前一个，只能在于

运行时完成，后者显然时可能的，但是可能会导致产生大量的不同的类一可怕的事情。

2.问题

你如何组织你的代码使其可以容易的添加基本的或者一些很少用到的特性，而不是直接不额

外的代码写在你的类的内部？

3.解决方案

装饰器模式：动态地给一个对象添加一些额外的职责或者行为。就增加功能来说，

Decorator模式相比生成子类更为灵活。

装饰器模式提供了改变子类的灵活方案。装饰器模式在不必改变原类文件和使用继承

的情况下，动态的扩展个对象的功能。它是通过创建个包装对象，也就是装饰来包裹真

实的对象。

当用于一组子类时，装饰器模式更加有用。如果你拥有一族子类（从•个父类派生而

来），你需要在与子类独立使用情况下添加额外的特性，你可以使用装饰器模式，以避免代

码重复和具体子类数量的增加。

4.适用性

以下情况使用Decorator模式

1)-在不影响其他对象的情况下，以动态、透明的方式给单个对象添加职责。

2)-处理那些可以撤消的职责。

3)«当不能采用生成子类的方法进行扩充时。一种情况是，可能有大量独立的扩展,

为支持每一种组合将产生大量的子类，使得子类数目呈爆炸性增长。

另一种情况可能是因为类定义被隐藏，或类定义不能用于生成子类。

5.

结构

uml如图：

6.构建模式的组成

抽象组件角色(Component)：定义一个对象接口，以规范准备接受附加责任的对象,

即可以给这些对象动态地添加职责。

具体组件角色(ConcreteComponent):被装饰者，定义一个将要被装饰增加功能的类。

可以给这个类的对象添加一些职责

抽象装饰器(Decorator):维持•个指向构件Component对象的实例，

并定义一个与抽象组件角色Component接口一致的接口

具体装饰器角色(ConcreteDecorator):向组件添加职责。

7.效果

装饰模式的特点：

(1)装饰对象和真实对象有相同的接口。这样客户端对象就可以以和真实对象相同

的方式和装饰对象交互。

(2)装饰对象包含一-个真实对象的索引(reference)

(3)装饰对象接受所有的来自客户端的请求。它把这些请求转发给真实的对象。

(4)装饰对象可以在转发这些请求以前或以后增加一些附加功能。这样就确保了在运

行时，不用修改给定对象的结构就可以在外部增加附加的功能。在面向对象的设计中，通常

是通过继承来实现对给定类的功能扩展。

Decorator模式至少有两个主要优点和两个缺点：

1)比静态继承更灵活：与对象的静态继承(多重继承)相比，Decorator模式提供了更加

灵活的向对象添加职责的方式。可以用添加和分离的方法，用装饰在运行时刻增加和删除职

责。相比之下，继承机制要求为每个添加的职责创建一个新的子类。这会产生许多新的类，

并且会增加系统的复杂度。此外，为一个特定的Component类提供多个不同的Decorator

类，这就使得你可以对一些职责进行混合和匹配。使用Decorator模式可以很容易地重复添

加一个特性。

2)避免在层次结构高层的类有太多的特征Decorator模式提供了•种“即用即付”的方法来

添加职责。它并不试图在一个复杂的可定制的类中支持所有可预见的特征，相反，你可以定

义一个简单的类，并且用Decorator类给它逐渐地添加功能。可以从简单的部件组合出复

杂的功能。这样，应用程序不必为不需要的特征付出代价。同时更易于不依赖于Decorator

所扩展(甚至是不可预知的扩展)的类而独立地定义新类型的Decoratoro扩展一个复杂类

的时候，很可能会暴露与添加的职责无关的细节。

3)Decorator与它的Component不一样Decorator是--个透明的包装。如果我们从对象标

识的观点出发，一个被装饰了的组件与这个组件是有差别的，因此，使用装饰不应该依赖对

象标识。

4）有许多小对象采用Decorator模式进行系统设计往往会产生许多看上去类似的小对象，

这些对象仅仅在他们相互连接的方式上有所不同，而不是它们的类或是它们的属性值有所不

同。尽管对于那些了解这些系统的人来说，很容易对它们进行定制，但是很难学习这些系统，

排错也很困难。

8.实现

使用《php设计模式》里面的例子。

看看以下例子，你可以更好的理解这种观点。考虑一个建立在组件概念上的“form”表单库，

在那里你需要为每•个你想要表现的表单控制类型建立一个类。这种类图可以如下所示：

SelectandTextinput类是组件类的子类。假如你想要增加一个"labeled"带标签的组

件一一个输入表单告诉你要输入的内容。因为任何一个表单都可能需要被标记，你可能会象

这样继承每•个具体的组件：

Widget

工

SelectTextinput

•♦•paint()fpaint()

上面的类图看起来并不怎么坏，卜一面让我们再增加一些特性。表单验证阶段，你希望能够指

出一个表单控制是否合法。你为非法控制使用的代码又一次继承其它组件，因此又需要产生

大量的子类：

Widget

♦pa5int。

SelectTextinput

+paIint()+paiInt{)

LabeledSelectLabeledTextlnput

+paint()+paint()

这个类看起来并不是太坏，所以让我们增加一些新的功能。在结构有效性确认中你需要指出

结构是否是有效的。你需要让你检验有效性的代码也可以应用到其它部件，这样不用再更多

的子类上进行有效性验证。

这里子类溢出并不是唯一的问题。想-想那些重复的代码,你需要重新设计你的整个类层次。

有没有更好的方法！确实，装饰器模式是避免这种情况的好方法。

装饰器模式结构上类似与代理模式。一个装饰器对象保留有对对象的引用，而且忠实的重新

建立被装饰对象的公共接口。装饰器也可以增加方法，扩展被装饰对象的接口，任意重载方

法，甚至可以在脚本执行期间有条件的重载方法。

为了探究装饰器模式，让我们以前面讨论过的表单组件库为例，并且用装饰器模式而不是继

承，实现"lable"和"invalidation”两个特性。

样本代码：

组件库包含哪些特性？

1.容易创建表单元素

2.将表单元素以html方式输出

3.在每个元素上实现简单的验证

本例中，我们创建一个包含姓，名，邮件地址，输入项的表单。所有的区域都是必须的，而

且E-mail必须看起来是有效的E-mail地址。用HTML语言表示，表单的代码象下面所示：

1.<formaction=wformpage.php,Jmethod="post”>

2.<b>FirstName:</b><inputtype="text"name="fname“value=w,,xbr>

3.<b>LastName:</b><inputtype=JJtextJJname=wlnameJ,value=J,wxbr>

4.<b>Email:</b><inputtype="text"name=,,email,,value=w,,xbr>

5.〈inputtype=wsubmitwvalue=,JSubmitw>

6.</form>

增加一些css样式后，表单渲染出来如卜.图所示:

「DecoratorExample

我们使用装饰器代码:

1.<?php

2,/**

3.*装饰器模式的组成：

4.*抽象组件例色(Component):定义•个对象接口，以规迫准备接受附加责任的对象，即川

这些对象动态地添加职责。

5.1|:L'l--'!'fL0':l21(ConcreteComponent):被装怖捍.定义3恪嬖被装饰增加功能的类：可以

给这个类的对象添加一些职责。

6.*抽象装饰器(Decorator):维甘个指同构仪Component对象的实例，并定义一个与抽象组

件角色Component接口一致的接口。

7.*具体装饰器角色(ConcreteDecorator):向组件添加职责。

8.*@authorguisu

9.*@version1.0

10.*/

11.

12,/**

13.*抽象组件ffj色1Component)

14.*

15.*/

16.classComponentwidget{

17.functionpaint(){

18.return$this->_asHtml();

19.}

20.}

21.

22./**

23.*

24.*具体组件角色(ConcreteComponent):

25.*让我们以一个基木的text输入组件开始°它(组件)必须耍包含输入M域的丁产(name)inj

且输入内容可以以HTML的方式渲染。

26.*

27.*/

28.classConereteComponentTextInputextendsComponentwidget{

29.

30.protected$_name;

31.protected$__value;

32.

33.functionTextlnput($name,$value=1'){

34.$this->_name=$name;

35.$this->_value=$value;

36.}

37.

38.function_asHtml(){

39.return'<inputtype="text"name="'.$this->_name.'"value="1.$this->_v

40.

41.}

42.

43.}

44,/**

45.*抽象装饰器(Decorator):维扪一个指向构件Component对象的文例，并定义个叮抽象舛.

件角色Component接口一,致的接口。

46.*

47.*我们进入有能够统增加(一些特性)能力的装饰器模式。

48.*作为开始，我们建M一个伴通的可以被，履产1乂体的牡定装饰器的WidgetDecorator类

至少WidgetDecorator类应该能够在它的构造函数中接受一个组件，

49.J；paint

50.*

51.*/

52.classWidgetDecorator{

53.

54.protected$_widget;

55.function_construct(&$widget){

56.$this->_widget=Jwidget;

57.}

58.functionpaint(){

59.return$this->_widget->paint();

60.

61.}

62.

63.}

64,/**

65.*具体装饰器用色(ConcreteDecorator):

66.*为建,工一个标签(lable),需要传入lable的内容.以及原始的•

67.*仃标签的组件也需要复制paint方法

68.*

69.*/

70.

71.

72.classConereteDecoratorLabeledextendsWidgetDecorator{

73.

74.protected$_label;

75.

76.function_construct($label,,&$widget){

77.$this->__label=$label;

78.parent::_construct($widget);

79.}

80.

81.functionpaint(){

82.return'<b>',$this->__label.':</b>',$this->_widget->paint();

83.}

84.

85.}

86.

87.

88,/**

89.*实现

90.*

91.*/

92.classFormHandler{

93.functionbuild(&$post){

94.returnarray(

95.newConcreteDecoratorLabeled('FirstName',newConereteComponentTextl

nput('fname',$post->get('fname')))

96.,newConcreteDecoratorLabeled('LastName',newConcreteComponentTextl

nput('Iname',$post->get('Iname')))

97.,newConcreteDecoratorLabeled('Email',newConcreteComponentTextlnput

(*email'y$post->get('email')))

98.);

99.

100.}

101.

102.

103.

104.}

105.

106./**

107.*通过$_post提交的数掂

108.*/

109.

110.classPost{

111.

112.private$store=array();

113.

114.functionget($key){

115.if(array_key_exists($keyj$this->store))

116.return$this->store[$key];

117.}

118.

119.functionset($key,$val){

120.$this->store[$key]=$val;

121.}

122.

123.staticfunctionautoFill(){

124.$ret=newself();

125.foreach($_POSTas$key=>$value){

126.$ret->set($key,$value);

127.}

128.return$ret;

129.}

130.

131.}

132.

133.

134.?>

以创建一个php脚本使用FormHandler类来产生HTML表单：

1.<formaction=wformpage.phpJJmethod=wpostw>

2.

3.<?php

4.$post=&Post::autoFill();

5.$form=FormHandler::build($post);

6.foreach($formas$widget){

7.echo$widget->paint()}"<br>\n";

8・}

9.?>

10.

11.<inputtype=wsubmitwvalue=wSubmitw>

12.

13.</form>

现在，你己经拥有了个提交给它自身并且能保持posted数据的表单处理(formhandler)

类。

现在。我们继续为表单添加一些验证机制。方法是编辑另一个组件装饰器类来表达一个

"invalid”状态并扩展FormHandler类增加一个validate()方法以处理组件示例数组。如果

组件非法("invalid"),我们通过•个"invalid"类将它包装在vspan>元素中。

1.<?php

2.

3.classInvalidextendsWidgetDecorator{

4

5.functionpaint(){

6.return'<spanclass="invalid">*.$this->widget->paint().'</span>';

7.)

8.)

FormHandler新加方法validate：

1./**

2.*实现

3.*

4.*/

5.classFormHandler{

6.functionbuild(&$post){

7.returnarray(

8.newConcreteDecoratorLabeled('FirstName',newConcreteComponentTextl

nput('fname',$post->get('fname')))

9.?newConcreteDecoratorLabeled('LastName',newConcreteComponentTextl

nput('Iname',$post->get('Iname')))

10.,newConcreteDecoratorLabeled('Email',newConcreteComponentTextlnput

('email',$post->get('email')))

11.)；

12.

13.}

14.

15.functionvalidate(ASform,&$post){

16.$valid=true;

17.//firstnamerequired

18.if(!strlen($post->get('fname'))){

19.$form[0]=&newInvalid($form[0]);

20.$valid=false;

21.}

22.

23.//lastnamerequired

24.if(!strlen($post->get('Iname'))){

25.$form[l]=&newInvalid($form[l]);

26.$valid=false;}

27.//emailhastolookreal

28.if(!preg_match('~\w+@(\w+\.)+\w+-'

29.3post->get('email'))){

30.$form[2]=&newInvalid($form[2]);

31.$valid=false;

32.)

33.return$valid;

34.

35.}

36.

37・}

最后结果:

1.<html>

2.

3.<head>

4.<title>DecoratorExample</title>

5.<styletype="text/css">

6..invalid{color:red;}

7..invalidinput{background-color:red;color:yellow;}

8.#myforminput{position:absolute;left:110px;width:250px;fon

t-weight:bold;}

9.</style>

10.</head>

11.<body>

12.<formaction="<?phpecho$_SERVER["PHP_SELF"];?>"method="post">

13.<divid="myform">

14.<?php

15.$pos=&Post::autoFill();

16.$form=FormHandler::build($post);

17.if($_POST){FormHandler::validate($form?$post);

18.}

19.foreach($formas$widget){

20.echo$widget->paint()>"<br>\n";

21・)

22.?>

23.

24.</div>

25.<inputtype="submit"value="Submit">

26.</form>

27.</body>

28.</html>

9.装饰器模式与其他相关模式

1)Adapter模式：Decorator模式不同于Adapter模式，因为装饰仅改变对象的职责而

不改变它的接口；而适配器将给对象一个全新的接口。

2)Composhe模式：可以将装饰视为一个退化的、仅有一个组件的组

合。然而，装饰仅给对象添加一些额外的职责一它的目的不在于对象聚集。

3)Strategy模式：用一个装饰你可以改变对象的外表；而Strategy模

式使得你可以改变对象的内核。这是改变对象的两种途径。

10.总结

1)使用装饰器设计模式设计类的目标是：

不必重写任何已有的功能性代码，而是对某个基于对象应用增量变化。

2)

装饰器设计模式采用这样的构建方式：在主代码流中应该能够直接插入一个或多个更改或

“装饰”目标对象的装饰器，

同时不影响其他代码流。

3)

Decorator模式采用对象组合而非继承的手法，实现了在运行时动态的扩展对象功能的能

力，

而且可以根据需要扩展多个功能，避免了单独使用继承带来的“灵活性差”和“多子类衍生问

题”。

同时它很好地符合面向对象设计原则中“优先使用对象组合而非继承”和“开放-封闭”原则。

也许装饰器模式最重要的一个方面是它的超过继承的能力。“问题”部分展现了一个使用继承

的子类爆炸。

基于装饰器模式的解决方案，UML类图展现了这个简洁灵活的解决方案。

设计模式（十）享元模式Flyweight（结构型）

说明：

相对于其它模式，Flyweight模式在PHP实现似乎没有太大的意义，因为PHP的生命周

期就在一个请求，请求执行完了，php占用的资源都被释放。我们只是为了学习而简单做

了介绍。

1.概述

面向对象技术可以很好地解决系统一些灵活性或可扩展性或抽象性的问题,但在很多情况下

需要在系统中增加类和对象的个数。当对象数量太多时，将导致运行代价过高，带来性能下

降等问题。比如：

例子1:图形应用中的图元等对象、字处理应用中的字符对象等。

2.解决方案:

享元模式（Flyweight）：对象结构型模式运用共享技术有效地支持大量细粒度的

对象。

它使用共享物件，用来尽可能减少内存使用量以及分享资讯给尽可能多的相似物件;

它适合用于当大量物件只是重复因而导致无法令人接受的使用大量内存。通常物件中的部分

状态是可以分享。常见做法是把它们放在外部数据结构，当需要使用时再将它们传递给享元。

4.适用性

1）一个应用程序使用大量相同或者相似的对象，造成很大的存储开销。

2）对象的大部分状态都可以外部化，可以将这些外部状态传入对象中。

3）如果删除对象的外部状态，那么可以用相对较少的共享对象取代很多组对象。

4）应用程序不依赖于对象标识。由于Flyweight对象可以被共享，对于概念上明显有别的

对象，标识测试将返回真值。

5）使用享元模式需要维护•个存储享元对象的享元池，而这需要耗费资源，因此，应当在

多次重复使用享元对象时才值得使用享元模式

5.结构

6.构建模式的组成

1)抽象享元类(Flyweight):

描述一个接口，通过这个接口flyweight可以接受并作用于外部状态。

2)具体享元类(ConcreteFlyweight):实现Flyweight接口，并为内部状态(如果有的话)

增加存储空间

。ConcreteFlyweight对象必须是可共享的。它所存储的状态必须是内部的；即，它必

须独立于ConcreteFlyweight对象的场景。

3)非共享具体享元类(UnsharedConcreteFlyweight)：—并非所有的Flyweight子类都

需要被共享。Flyweight接口使共享成为可能，但它并不强制共享。在Flyweight对象结构

的某些层次,UnsharedConcreteFlyweight对象通常将ConcreteFlyweight对象作为子节点。

4）享元工厂类（FlyweightFactory）:创建并管理flyweight对象，确保合理地共享

flyweighto本角色必须保证享元对象可以被系统适当地共享。当一个客户端对象调用一个享

元对象

flyweight的时候，享元工厂角色（FlyweightFactory对象）会检查系统中是否已经有

一个符合要求的享元对象。如果已经有了，享元工厂角色就应当提供这个已有的享元对象；

如果系统中没有一个适当的享元对象的话，享元工厂角色就应当创建一个合适的享元对象。

5）客户（Client）:维持一个对flyweight的引用。计算或存储一个（多个）flyweight

的外部状态。

7.

效果

享元模式的优点：

1）享元模式的优点在于它可以极大减少内存中对象的数量，使得相同对象或相似对象在内

存中只保存一份。

2）享元模式的外部状态相对独立，而且不会影响其内部状态，从而使得享元对象可以在不

同的环境中被共享。

享元模式的缺点：

1）享元模式使得系统更加复杂，需要分离出内部状态和外部状态，这使得程序的逻辑复杂

化。

2）为了使对象可以共享，享元模式需要将享元对象的状态外部化，而读取外部状态使得运

行时间变长。

8.实现

享元模式可以分成单纯享元模式和复合享元模式两种形式。

【单纯享元模式】

在单纯的享元模式中，所有的享元对象都是可以共享的。

源代码:

1.<?php

2.

3./**

4.*单纯享元模式

5.*@authorguisu

6.*/

7.

8,/**

9.*抽象享元角色

10.*/

11.abstractclassFlyweight{

12.

13./**

14.*示意性方法

15.*@paramstring{state外部状态

16.*/

17.abstractpublicfunctionoperation($state);

18.}

19.

20,/**

21.*具体享元角色

22.*/

23.classConcreteFlyweightextendsFlyweight{

24.

25.private$_intrinsicState=null;

26.

27,/**

28.*构造方法

29.*@paramstring$state内部状态

30.*/

31.publicfunction_construct($state){

32.$this->_intrinsicState=$state;

33・)

34.

35.publicfunctionoperation($state){

36.echo'ConcreteFlyweightoperation.IntrinsicState=*.$this->_intrinsicS

tate

37..'ExtrinsicState=',{state,'<br/>';

38.}

39.

40.}

41.

42.

43,/**

44.*享元工厂角色

45.*/

46.classFlyweightFactory{

47.

48.private$_flyweights;

49.

50.publicfunction_construct(){

51.$this->_flyweights=array();

52.)

53.

54.publicfunctiongetFlyweigth({state){

55.if(isset($this->_flyweights[$state])){

56.return$this->_flyweights[$state];

57.}else{

58.return$this->_flyweights[$state]=newConcreteFlyweight($state);

59.}

60.}

61.

62.}

63.

64.classClient{

65.staticfunctionmain(){

66.$flyweightFactory=newFlyweightFactory();

67.$flyweight=$flyweightFactory->getFlyweigth('stateA');

68.$flyweight->operation('otherstateA');

69.

70.lyweight=$flyweightFactory->getFlyweigth('stateB')5

71.$flyweight->operation('otherstateB');

72.

73.)

74.}

75.

76.

77.

78.?>

【复合享元模式】

复合享元模式对象是由一些单纯享元使用合成模式加以复合而成

复合亭元角色所代表的对象是不可以共享的，但是一个复合享元对象可以分解成为多个本身

是单纯享元对象的组合。

1.<?php

2.

3,/**

4.*复合享元模式

5.*

6.*/

7.

8./**

9.*抽象李元角色

10.*/

11.abstractclassFlyweight{

12.

13,/**

14.*示意性方法

15.*@paramstring{state外部状态

16.*/

17.abstractpublicfunctionoperation($state);

18.}

19.

20,/**

21.*具体字元角色

22.*/

23.classConcreteFlyweightextendsFlyweight{

24.

25.private$_intrinsicState=null;

26.

27,/**

28.*构造方法

29.*@paramstring$state内部状态

30.*/

31.publicfunction_construct($state){

32.$this->_intrinsicState=$state;

33-)

34.

35.publicfunctionoperation($state){

36.echo'ConcreteFlyweightoperation^IntrinsicState='.$this->_intrinsicS

tate

37.・1ExtrinsicState='.$state.'<br/>';

38.}

39.

40.}

41.

42,/**

43.*不火不的JL体享心客八端“接调用

44.*/

45.classUnsharedConcreteFlyweightextendsFlyweight{

46.

47.private$_flyweights;

48.

49,/**

50.*构造方法

51.*@paramstringfstate内部状态

52.*/

53.publicfunction_construct(){

54.$this->_flyweights=array();

55・}

56.

57.publicfunctionoperation($state){

58.foreach($this->_flyweightsas$flyweight){

59.$flyweight->operation($state);

60.}

61.}

62.

63.publicfunctionadd($state^Flyweight$flyweight){

64.$this->_flyweights[$state]={flyweight;

65.}

66.

67.}

68.

69,/**

70.*字元」」.角色

71.*/

72.classFlyweightFactory{

73.

74.private$_flyweights;

75.

76.publicfunction_construct(){

77.$this->_flyweights=array();

78.}

79.

80.publicfunctiongetFlyweigth($state){

81.if(is_array($state)){//复合螳式

82.$uFlyweight=newUnsharedConcreteFlyweight();

83.

84.foreach($stateas$row){

85.$uFlyweight->add($row,$this->getFlyweigth($row))