面向对象方法与技术：设计模式实践课件

面向对象的技术与方法共151页第2页Composite(组合)模式目的：将对象组合成树形结构以表示“部分-整体”的层次结构。Composite使得用户对单个对象和组合对象的使用具有一致性。共151页第3页Composite(组合)模式动机：在绘图编辑器和图形捕捉系统这样的图形应用程序中，用户可以使用简单的组件创建复杂的图表。用户可以组合多个简单组件以形成一些较大的组件，这些组件又可以组合成更大的组件。一个简单的实现方法是为Text和Line这样的图元定义一些类，另外定义一些类作为这些图元的容器类(Container)。共151页第4页Composite(组合)模式存在的问题：使用这些类的代码必须区别对待图元对象与容器对象，而实际上大多数情况下用户认为它们是一样的。对这些类区别使用，使得程序更加复杂。共151页第5页Composite(组合)模式

Composite模式描述了如何使用递归组合，使得用户不必对这些类进行区别，如图所示：共151页第6页Composite(组合)模式共151页第7页Composite(组合)模式

Picture类定义了一个Graphic

对象的聚合。Picture

的Draw操作是通过对它的子部件调用Draw实现的，Picture还用这种方法实现一些与其子部件相关的操作。由于Picture接口与Graphic接口是一致的，因此Picture对象可以递归地组合其他Picture对象。共151页第8页Composite(组合)模式

下图是一个典型的由递归组合的Graphic对象组成的组合对象结构：共151页第9页Composite(组合)模式适用性你想表示对象的部分-整体层次结构。你希望用户忽略组合对象与单个对象的不同，用户将统一地使用组合结构中的所有对象。共151页第10页Composite(组合)模式结构共151页第11页Composite(组合)模式共151页第12页Composite(组合)模式协作用户使用Component类接口与组合结构中的对象进行交互。如果接收者是一个叶节点,则直接处理请求。如果接收者是Composite,它通常将请求发送给它的子部件，在转发请求之前与/或之后可能执行一些辅助操作。共151页第13页Composite(组合)模式效果定义了包含基本对象和组合对象的类层次结构。

简化客户代码使得更容易增加新类型的组件使你的设计变得更加一般化共151页第14页Composite(组合)模式代码示例计算机这样的设备经常被组装成部分－整体层次结构。例如，底盘可包含驱动装置和平面板，总线含有多个插件，机柜包括底盘、总线等。共151页第15页Composite(组合)模式Equipment类为在部分－整体层次结构中的所有设备定义了一个接口。共151页第16页Composite(组合)模式共151页第17页Composite(组合)模式Equipment的子类包括表示磁盘驱动器、集成电路和开关的Leaf类：共151页第18页Composite(组合)模式CompositeEquipment是包含其他设备的基类，它也是Equipment的子类。共151页第19页Composite(组合)模式共151页第20页Composite(组合)模式NetPrice的缺省实现使用CreateIterator来累加子设备的实际价格。共151页第21页Composite(组合)模式我们将计算机的底盘表示为CompositeEquipment的子类Chassis。Chassis从CompositeEquipment继承了与子类有关的那些操作。共151页第22页Composite(组合)模式共151页第23页Composite(组合)模式我们可用相似的方式定义其他设备容器，如Cabinet和Bus。这样我们就得到了组装一台(非常简单)个人计算机所需的所有设备。共151页第24页Composite(组合)模式共151页第25页Composite(组合)模式说明：

Composite模式在实现中有一个问题就是要提供对于子节点（Leaf）的管理策略，这里使用的是STL中的list，可以提供其他的实现方式，如数组、Hash表等。共151页第26页Composite(组合)模式共151页第27页Composite(组合)模式MFC中的CWnd为典型的组合模式Composite(组合)模式总结：1）组合模式解耦了客户程序与复杂元素内部结构，从而使客户程序可以向处理简单元素一样来处理复杂元素。2）如果想要创建层次结构，并可以在其中以相同的方式对待所有元素，那么组合模式就是最理想的选择。共151页第28页共151页第29页FACADE（外观）模式问题：接口调用的问题等等…共151页第30页FACADE（外观）模式目的：使系统的各子系统之间关联最小，引入一个Facade对象，为子系统提供一个简单的、泛化的设施。为子系统中的一组接口提供一个一致的界面，Facade模式定义了一个高层接口，这个接口使得这一子系统更加容易使用。共151页第31页FACADE（外观）模式动机将一个系统划分成为若干个子系统有利于降低系统的复杂性。一个常见的设计目标是使子系统间的通信和相互依赖关系达到最小。达到该目标的途径之一是就是引入一个外观（facade）对象，它为子系统中较一般的设施提供了一个单一而简单的界面。共151页第32页FACADE（外观）模式FACADE（外观）模式共151页第33页共151页第34页FACADE（外观）模式共151页第35页FACADE（外观）模式Facade(Compiler)

—

知道哪些子系统类负责处理请求。

—

将客户的请求代理给适当的子系统对象。Subsystemclasses(Scanner、Parser、ProgramNode等)

—

实现子系统的功能。

—

处理由Facade对象指派的任务。

—

没有facade的任何相关信息；即没有指向

facade的指针。共151页第36页FACADE（外观）模式适用性当你要为一个复杂子系统提供一个简单接口时。子系统往往会非常复杂，但是其接口应该尽可能简单，特别是对于一般用户而言当客户程序与抽象类的实现部分之间存在着很大的依赖性时，Façade模式可以降低依赖性。在多个子系统的结构中，使用facade模式定义子系统的入口点，有助于降低各子系统之间的依赖性。在层次化结构中，可以使用Facade模式定义系统中每一层的入口。共151页第37页FACADE（外观）模式结构共151页第38页FACADE（外观）模式协作客户程序通过发送请求给Facade的方式与子系统通讯，Facade将这些消息转发给适当的子系统对象。尽管是子系统中的有关对象在做实际工作，但Facade模式本身也必须将它的接口转换成子系统的接口。使用Facade的客户程序不需要直接访问子系统对象。共151页第39页FACADE（外观）模式效果1)它对客户屏蔽子系统组件，因而减少了客户处理的对象的数目并使得子系统使用起来更加方便。

2)它实现了子系统与客户之间的松耦合关系，而子系统内部的功能组件往往是紧耦合的。3)如果应用需要，它并不限制它们使用子系统类。共151页第40页FACADE（外观）模式代码示例如何在一个编译子系统中使用Facade模式？共151页第41页FACADE（外观）模式Scanner类接收字符流并产生一个标识符流，一次产生一个标识符(token)。共151页第42页FACADE（外观）模式Parser类由Scanner生成的标识符构建一棵语法分析树。共151页第43页FACADE（外观）模式Parser回调ProgramNodeBuilder逐步建立语法分析树，共151页第44页FACADE（外观）模式共151页第45页FACADE（外观）模式ProgramNode定义了一个接口用于操作程序节点和它的子节点（如果有的话）。共151页第46页FACADE（外观）模式共151页第47页FACADE（外观）模式Traverse操作以一个CodeGenerator对象为参数，ProgramNode子类使用这个对象产生机器代码，共151页第48页FACADE（外观）模式ProgramNode的每个子类在实现Traverse时，对它的ProgramNode子对象调用Traverse。每个子类依次对它的子节点做同样的动作，这样一直递归下去。共151页第49页FACADE（外观）模式例如，ExpressionNode像这样定义Traverse：共151页第50页Compiler类

共151页第51页FACADE（外观）模式说明：

Facade模式在高层提供了一个统一的接口，解耦了系统。Mediator模式和Facade有类似的地方。但是Mediator主要目的是对象间的访问的解耦（通讯时候的协议）。FACADE（外观）模式Facade的几个要点1)从客户程序的角度来看，Facade模式不仅简化了整个组件系统的接口，同时对于组件内部与外部客户程序来说，从某种程度上也达到了一种“解耦”的效果——内部子系统的任何变化不会影响到Façade接口的变化。

2)Façade设计模式更注重从架构的层次去看整个系统，而不是单个类的层次。Façade很多时候更是一种架构设计模式。

3)Façade设计模式并非一个集装箱，可以任意地放进任何多个对象。Façade模式中组件的内部应该是“相互耦合关系比较大的一系列组件”，而不是一个简单的功能集合。共151页第52页FACADE（外观）模式与其他模式的区分

Façade模式注重简化接口

Adapter模式注重转换接口

Bridge模式注重分离接口（抽象）与其实现

Decorator模式注重稳定接口的前提下为对象扩展功能。共151页第53页FACADE（外观）模式保安系统的例子共151页第54页FACADE（外观）模式改进方法——系统的控制台，作为保安系统的用户界面共151页第55页共151页第56页Command模式目的：将一个请求封装为一个对象，从而使你可用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤消的操作。共151页第57页Command模式共151页第58页Command模式

用Command对象可很容易的实现菜单（Menu），每一菜单中的选项都是一个菜单项（MenuItem）类的实例。一个Application类创建这些菜单和它们的菜单项以及其余的用户界面。该Application类还跟踪用户已打开的Document对象。共151页第59页Command模式

该应用为每一个菜单项配置一个具体的Command子类的实例。当用户选择了一个菜单项时，该MenuItem对象调用它的Command对象的Execute方法，而Execute执行相应操作。

MenuItem对象并不知道它们使用的是Command的哪一个子类。Command子类里存放着请求的接收者，而Execute操作将调用该接收者的一个或多个操作。共151页第60页Command模式共151页第61页Command模式共151页第62页Command模式

有时一个MenuItem需要执行一系列命令。例如，使一个页面按正常大小居中的MenuItem可由一个CenterDocumentCommand对象和一个NormalSizeCommand对象构建。因为这种需将多条命令串接起来的情况很常见，我们定义一个MacroCommand类来让一个MenuItem执行任意数目的命令。共151页第63页Command模式共151页第64页Command模式适用性像上面讨论的MenuItem对象那样，抽象出待执行的动作以参数化某对象。你可用过程语言中的回调（callback）函数表达这种参数化机制。所谓回调函数是指函数先在某处注册，而它将在稍后某个需要的时候被调用。Command模式是回调机制的一个面向对象的替代品。共151页第65页Command模式支持取消操作。Command的Excute操作可在实施操作前将状态存储起来，在取消操作时这个状态用来消除该操作的影响。Command接口必须添加一个Unexecute操作，该操作取消上一次Execute调用的效果。执行的命令被存储在一个历史列表中。可通过向后和向前遍历这一列表并分别调用Unexecute和Execute来实现重数不限的“取消”和“重做”。共151页第66页Command模式

支持修改日志，这样当系统崩溃时，这些修改可以被重做一遍。在Command接口中添加装载操作和存储操作，可以用来保持变动的一个一致的修改日志。从崩溃中恢复的过程包括从磁盘中重新读入记录下来的命令并用Execute操作重新执行它们。共151页第67页Command模式结构共151页第68页Command模式协作•Client创建一个ConcreteCommand对象并指定它的Receiver对象。•某Invoker对象存储该ConcreteCommand对象。•该Invoker通过调用Command对象的Execute操作来提交一个请求。若该命令是可撤消的，ConcreteCommand就在执行Execute操作之前存储当前状态以用于取消该命令。共151页第69页Command模式ConcreteCommand对象调用它的Receiver的一些操作以执行该请求共151页第70页Command模式效果将调用操作的对象与知道如何实现该操作的对象解耦。增加新的Command很容易，因为这无需改变已有的类。你可将多个命令装配成一个复合命令。例如是前面描述的MacroCommand类。一般说来，复合命令是Composite模式的一个实例。共151页第71页Command模式代码示例抽象的Command类：共151页第72页Command模式OpenCommand打开一个名字由用户指定的文档。OpenCommand的构造函数需要一个

Application对象作为参数。AskUser是一个提示用户输入要打开的文档名的实现例程。共151页第73页Command模式共151页第74页Command模式共151页第75页Command模式PasteCommand需要一个Document对象作为其接收者。该接收者将作为一个参数给

PasteCommand的构造函数。共151页第76页Command模式共151页第77页Command模式对于简单的不能取消和不需参数的命令,可以用一个类模板来参数化该命令的接收者。我们将为这些命令定义一个模板子类SimpleCommand.用Receiver类型参数化SimpleCommand，并维护一个接收者对象和一个动作之间的绑定,而这一动作是用指向一个成员函数的指针存储的。共151页第78页Command模式共151页第79页Command模式构造器存储接收者和对应实例变量中的动作。Execute操作实施接收者的这个动作。共151页第80页Command模式创建一个调用Myclass类的一个实例上的Action的Command对象共151页第81页Command模式MacroCommand管理一个子命令序列，它提供了增加和删除子命令的操作。这里不需要显式的接收者，因为这些子命令已经定义了它们各自的接收者。共151页第82页Command模式共151页第83页Command模式MacroCommand的关键是它的Execute成员函数。它遍历所有的子命令并调用其各自的Execute操作。共151页第84页Command模式共151页第85页Command模式应用：

Command模式在界面设计中应用广泛。Java的Swing中菜单命令都是使用Command模式。共151页第86页MEMENTO（备忘录）模式意图在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样以后就可将该对象恢复到原先保存的状态。共151页第87页MEMENTO（备忘录）模式动机为了允许用户取消不确定的操作或从错误中恢复过来，需要实现检查点和取消机制,而要实现这些机制，你必须事先将状态信息保存在某处，这样才能将对象恢复到它们先前的状态。事先将状态信息保存与对象的封装性冲突。共151页第88页MEMENTO（备忘录）模式可用备忘录(Memento)模式解决这一问题一个备忘录（memento）是一个对象,它存储另一个对象在某个瞬间的内部状态，而后者称为备忘录的原发器(originator)。当需要设置原发器的检查点时,取消操作机制会向原发器请求一个备忘录。原发器用描述当前状态的信息初始化该备忘录。只有原发器可以向备忘录中存取信息，备忘录对其他的对象“不可见”。共151页第89页MEMENTO（备忘录）模式图形编辑器共151页第90页图形编辑器的例子中,ConstraintSolver可作为一个原发器。下面的事件序列描述了取消操作的过程:1)作为移动操作的一个副作用,编辑器向ConstraintSolver请求一个备忘录。2)ConstraintSolver创建并返回一个备忘录,在这个例子中该备忘录是SolverState类的一个实例。SolverState备忘录包含一些描述ConstraintSolver的内部等式和变量当前状态的数据结构。MEMENTO（备忘录）模式共151页第91页MEMENTO（备忘录）模式3)此后,当用户取消移动操作时,编辑器将SolverState备忘录送回给ConstraintSolver。4)根据SolverState备忘录中的信息,ConstraintSolver改变它的内部结构以精确地将它的等式和变量返回到它们各自先前的状态。共151页第92页适用性必须保存一个对象在某一个时刻的(部分)状态,这样以后需要时它才能恢复到先前的状态。如果一个用接口来让其它对象直接得到这些状态，将会暴露对象的实现细节并破坏对象的封装性。MEMENTO（备忘录）模式共151页第93页结构MEMENTO（备忘录）模式共151页第94页Memento(备忘录，如SolverState)—

备忘录存储原发器对象的内部状态。原发器根据需要决定备忘录存储原发器的哪些内部状态。—

防止原发器以外的其他对象访问备忘录。

Originator(原发器，如ConstraintSolver)—

原发器创建一个备忘录,用以记录当前时刻它的内部状态。—

使用备忘录恢复内部状态.。MEMENTO（备忘录）模式共151页第95页Caretaker(负责人，如undomechanism)—

负责保存好备忘录。—

不能对备忘录的内容进行操作或检查。MEMENTO（备忘录）模式共151页第96页协作备忘录是被动的。管理器向原发器请求一个备忘录,保留一段时间后,将其送回给原发器,如下面的交互图所示：MEMENTO（备忘录）模式共151页第97页MEMENTO（备忘录）模式共151页第98页效果1)保持封装边界2)简化了原发器3)使用备忘录可能代价很高4)定义窄接口和宽接口5)维护备忘录的潜在代价MEMENTO（备忘录）模式共151页第99页实现下面是当实现备忘录模式时应考虑的两个问题:1)语言支持备忘录有两个接口:一个为原发器所使用的宽接口,一个为其他对象所使用的窄接口。理想的实现语言应可支持两级的静态保护。MEMENTO（备忘录）模式共151页第100页共151页第101页2)存储增量式改变如果备忘录的创建及其返回（给它们的原发器）的顺序是可预测的，备忘录可以仅存储原发器内部状态的增量改变。MEMENTO（备忘录）模式共151页第102页

代码示例此处给出的C++代码展示的是前面讨论过的ConstraintSolver的例子。

MoveCommand命令对象来执行(取消)一个图形对象从一个位置到另一个位置的移动变换。MEMENTO（备忘录）模式共151页第103页MEMENTO（备忘录）模式共151页第104页共151页第105页给定这些接口,我们可以实现MoveCommand的成员函数Execute和Unexecute如下:共151页第106页MEMENTO模式说明：A：定义：Memento对象是一个保存另外一个对象内部状态拷贝的对象，这样以后就可以将该对象恢复到原先保存的状态。B：Memento模式的用意是在不破坏封装的条件下，将一个对象的状态捕捉住，并外部化，存储起来，从而可以在将来合适的时候把这个对象还原到存储起来的状态。

共151页第107页MEMENTO模式C：Memento模式所涉及的角色有三个，备忘录角色、发起人角色和负责人角色。备忘录角色的作用：（1）将发起人对象的内部状态存储起来，备忘录可以根据发起人对象的判断来决定存储多少发起人对象的内部状态。（2）

备忘录可以保护其内容不被发起人对象之外的任何对象所读取。

共151页第108页MEMENTO模式发起人角色的作用：（1）

创建一个含有当前内部状态的备忘录对象。（2）使用备忘录对象存储其内部状态。负责人角色的作用：

（1）负责保存备忘录对象（2）不检查备忘录对象的内容。

共151页第109页Iterator模式目的：

Iterator模式是用来解决对一个聚合对象的遍历问题，将对聚合的遍历封装到一个类中进行，这样就避免了暴露这个聚合对象的内部表示的可能。共151页第110页Iterator模式动机一个聚合对象,如列表(list),应该提供一种方法来让别人可以访问它的元素，而又不需暴露它的内部结构.此外，针对不同的需要，可能要以不同的方式遍历这个列表。但是即使可以预见到所需的那些遍历操作，你可能也不希望列表的接口中充斥着各种不同遍历的操作。有时还可能需要在同一个表列上同时进行多个遍历。共151页第111页Iterator模式链表迭代器结构图：共151页第112页Iterator模式将遍历机制与列表对象分离使我们可以定义不同的迭代器来实现不同的遍历策略，而无需在列表接口中列举它们。例如,过滤表列迭代器(FilteringListIterator)可能只访问那些满足特定过滤约束条件的元素。注意：迭代器和列表是耦合在一起的，而且客户对象必须知道遍历的是一个列表而不是其他聚合结构。共151页第113页Iterator模式适用性：访问一个聚合对象的内容而无需暴露它的内部表示。支持对聚合对象的多种遍历。为遍历不同的聚合结构提供一个统一的接口(即,支持多态迭代)。共151页第114页Iterator模式结构：共151页第115页Iterator模式参与者

Iterator（迭代器）—

迭代器定义访问和遍历元素的接口。ConcreteIterator（具体迭代器）—

具体迭代器实现迭代器接口。—

对该聚合遍历时跟踪当前位置。

Aggregate（聚合）—

聚合定义创建相应迭代器对象的接口。共151页第116页Iterator模式ConcreteAggregate（具体聚合）—

具体聚合实现创建相应迭代器的接口，该操作返回ConcreteIterator的一个适当的实例。协作：

ConcreteIterator跟踪聚合中的当前对象，并能够计算出待遍历的后继对象。共151页第117页Iterator模式效果

1)它支持以不同的方式遍历一个聚合

2)迭代器简化了聚合的接口

3)在同一个聚合上可以有多个遍历共151页第118页Iterator模式代码示例：一个简单List类的实现,它是我们的基础库的一部分。我们将给出两个迭代器的实现,一个以从前到后的次序遍历该表列,而另一个以从后到前的次序遍历。共151页第119页Iterator模式共151页第120页Iterator模式共151页第121页Iterator模式共151页第122页Iterator模式共151页第123页Iterator模式共151页第124页Iterator模式共151页第125页Iterator模式ReverseListIterator的实现是几乎是一样的，只不过它的First操作将_current置于列表的末尾,而Next操作将_current减一，向表头的方向前进一步。共151页第126页Iterator模式共151页第127页Iterator模式共151页第128页Iterator模式讨论：

Iterator模式的应用很常见，我们在开发中就经常会用到STL中预定义好的Iterator来对STL类进行遍历（Vector、list等）。Composite模式中对Iterator模式的应用。Iterator模式Iterator模式的优点1）实现功能分离，简化容器接口。让容器只实现本身的基本功能，把迭代功能委让给外部类实现，符合类的设计原则。2）隐藏容器的实现细节。3）为容器或其子容器提供了一个统一接口，一方面方便调用；另一方面使得调用者不必关注迭代器的实现细节。4)可以为容器或其子容器实现不同的迭代方法或多个迭代方法。共151页第129页共151页第130页Prototype模式意图用原型实例指定创建对象的种类，并且通过拷贝这些原型创建新的对象。共151页第131页Prototype模式动机共151页第132页Prototype模式结构共151页第133页Prototype模式参与者•Prototype（Graphic）

—

声明一个克隆自身的接口。•ConcretePrototype（Staff、WholeNote、HalfNote）

—

实现一个克隆自身的操作。•Client（GraphicTool）

—

让一个原型克隆自身从而创建一个新的对象。共151页第134页Prototype模式代码示例：classPrototype{public:virtual~Prototype(){};virtualPrototype*Clone()const=0;protected:Prototype(){};};共151页第135页Prototype模式classConcretePrototype:publicPrototype{public:ConcretePrototype(){};ConcretePrototype(constConcretePrototype&cp);~ConcretePrototype(){};Prototype*Clone()const;};共151页第136页Prototype模式ConcretePrototype::ConcretePrototype(constConcretePrototype&cp){cout<<"ConcretePrototypecopy..."<<endl;}Prototype*ConcretePrototype::Clone()const{returnnewConcretePrototype(*this);}共151页第137页Prototype模式voidmain(){Prototype*p=newConcretePrototype();Prototype*p1=p->Clone();}共151页第138页Prototype模式说明：

Prototype模式的结构和实现都很简单，其关键就是（C++中）拷贝构造函数的实现方式。Java中类的clone方法即是prototype模式的实现。共151页第139页Prototype模式讨论：

Prototype模式通过复制原型（Prototype）而获得新对象创建的功能，这里Prototype本身就是“对象工厂”，实际上Prototype模式和Builder模式、AbstractFactory模式都是通过一个类（对象实例）来专门负责对象的创建工作（工厂对象），它们之间的区别是：Builder模式重在复杂对象的一步步创建（并不直接返回对象），

AbstractFactory模式重在产生多个相互依赖类的对象，而Prototype模式重在从自身复制自己创建新类。共151页第140页Builder模式意图将一个复杂对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示。共151页第141页Builder模式动机当我们要创建的对象很复杂的时候（通常是由很多其他的对象组合而成），我们要要复杂对象的创建过程和这个对象的表示（展示）分离开来，这样做的好处就是通过一步步的进行复杂对象的构建，由于在每一步的构造过程中可以引入参数，使得经过相同的步骤创建最后得到的对象的展示不一样。共151页第142页Builder模式RTF（RichTextFormat）文档交换格式的阅读器共151页第143页Builder模式适用性•当创建复杂对象的算法应该独立于该对象的组成部分以及它们的装配方式时。•当构造过程必须允许被构造的对象有不同的表示时。共151页第144页Builder模式结构共151页第145页Builder模式参与者•Builder（TextConverter）—

为创建一个Product对象的各个部件指定抽象接口。•ConcreteBuilder（ASCIIConverter、TeXConverter、TextWidgetConverter）—

实现Builder的接口以构造和装配该产品的各个部件。—

定义并明确它所创建的表示。—

提供一个检索产品的接口（例如，

GetASCIIText和GetTextWidget）。共151页第146页Builder模式

Director（RTFReader）—构造一个使用Builder接口的对象。

Product（ASCIIText、TeXText、TextWidget）

—表示被构造的复杂对象。ConcreteBuilder创建该产品的内部表示并定义它的装配过程。

—包含定义组成部件的类，包括将这些部件装配成最终产品的接口。共151页第147页Builder模式协作•客户创建Director对象，并用它所想要的Builder对象进行配置。•一旦产品部件被生成，导向器就会通知生成器。•生成器处理导向器的请求，并将部件添加到该产品中。•客户从生成器中检索产品。共151页第148页Builder模式交互图共151页第149页Builder模式效果1)它使你可以改变一个产品的内部表示2)它将构造代码和表示代码分开3)它使你可对构造过程进行更精细的控制共151页第150页Builder模式代码示例

首先假设一个复杂对象是由多个部件组成的,Builder模式是把复杂对象的创建和部件的创建分别开来,分别用Builder类和Director类来表示.

首先,需要一个接口,它定义如何创建复杂对象的各个部件:共151页第151页Builder模式classBuilder{public:

//创建部件A比如创建汽车车轮

virtualvoidbuildPartA(){};

//创建部件B比如创建汽车方向盘

virtualvoidbuildPartB(){};

//创建部件C比如创建汽车发动机

virtu