软件的可维护性与可复用性

模式:模式，即Pattern。其实就是解决某一类问题的要领论。把解决某类问题的要领总结归纳到理论高度，那就是模式。Alexander给出的经典界说是：每个模式都描述了一个在我们的情况中不停出现的问题，然后描述了该问题的解决方案的焦点。通过这种方法，你可以无数次地使用那些已有的解决方案，无需再重复相同的事情。模式有差别的领域，修建领域有修建模式，软件设计领域也有设计模式。当一个领域逐渐成熟的时候，自然会出现许多模式。设计模式和面向东西的设计模式:设计模式（Designpattern）是一套被重复使用、多数人知晓的、经太过类编目的、代码设计经验的总结。使用设计模式是为了可重用代码、让代码更容易被他人理解、包管代码可靠性。设计模式最初来源于修建学。GOF（“四人帮"，指Gamma,Helm,Johnson&Vlissides,Addison-Wesley四人）的《设计模式》（1995年出书）是第一次将设计模式提升到理论高度，并将之范例化，本系列文章主要就是解说这23种经典的设计模式。面向东西设计的模式，顾名思义，就是在面向东西阐发与设计中使用的设计模式，GOF23种设计模式同时也是面向东西的设计模式，本文不做区分。良好的设计模式运用可以实现软件设计的“高内聚、低耦合”，提高软件的复用性和可扩展性。框架:框架，即Framework。其实就是某种应用的半制品，就是一组组件，供你选用完成你自己的系统。简朴说就是使用别人搭好的舞台，你来做演出。并且，框架一般是成熟的，不停升级的软件。框架一般处在低层应用平台（如J2EE）和高层业务逻辑之间的中间层。架构：架构(Architecture)是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。架构是一个系统的草图。架构描述的东西是直接组成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，好比具体某个类大概东西。在面向东西领域中，组件之间的连接通常用接口来实现。一些刚入门的步伐员经常会殽杂“框架”和“架构”这两个名词，这里做了一下解释。我们为什么要使用设计模式呢？有人可能会说为了设计出"高内聚低耦合"的软件。"高内聚低耦合"的软件实际上也就是本文所说的具有可维护性和可复用性的软件。这篇文章主要解说两方面内容，这两方面是软件设计中很重要，也是很要害的内容，希望各人认真思考并深刻理解。第一部门就是关于软件的可维护性和可复用性的相关内容，第二部门就是在第一部门的底子上逐条解说面向东西软件设计的根本原则，本文内容都是些很理论性的东西，这些理论是软件设计的底子。通常有理论的地方，就有如何恰当的将理论应用到实践中去的问题，设计模式是对付学习00设计原则的具体指导，也就是说设计模式就是将这些理论应用到实践的一种成熟的方法。软件的可维护性和可复用性首先来上一段大家所说的话，很经典。“通常认为，一个易于维护的系统，就是复用率较高的系统；而一个复用率较高的系统，就是一个易于维护的系统。但是实际上，可维护性和可复用性是两个独立的目标，就像两只奔驰的兔子一样，并不总是偏向一致的。对付面向东西的软件系统设计来说，在支持可维护性(Maintainability)的同时，提高系统的可复用性(Reuseability)是一个焦点的问题。”《Java与模式》阎宏博士软件系统的可维护性：软件维护就是软件的再生。一个好的软件设计，必须能够允许新的设计要求以比力容易宁静稳的方法参加到已有的系统中去，从而使这个系统能够不停的的抖擞出活力。一个可维护性较好的系统，应当允许维护事情能够以容易、准确、宁静和经济的形式进行。【导致可维护性较低的原因】1、 过于僵硬：在系统中参加一个新的功效，不管巨细都很难，不但意味着制作一个独立的新的模块，并且因为这个新功效会波及许多其他模块，最后成跨越几个模块的窜改。2、 过于脆弱：与软件的过于僵硬同时存在，是软件系统在修改已有代码时过于脆弱。对一个地方的修改，往往会导致看上去没有什么干系的另外一个地方产生妨碍。3、复用率低：所谓复用，就是指一个软件的组成部门，可以在同一个项目的差别地方甚至另一个项目中重复使用。复用率低，指当一段代码，函数，模块的功效可以在新的模块或新的系统使用，但是已有代码依赖于其他许多东西，很难离开。4、黏度过高：一个窜改可以生存原始设计意图和原始设计框架的方法进行，也可以以破坏原始意图和框架进行。第一种要领对系统的未来有利，第二种措施是权宜之计，可以解决短期的问题，但是会牺牲中恒久的利益。如果一个系统中使用第二种要领比使用第一种要领容易，那么就是黏度过高。【设计的目标】1、可扩展性：新的性能可以很容易地参加到系统中去，就是可扩展性。这就是系统“过于僵硬”的属性的方面。2、灵活性：可以允许代码修改平稳地产生，而不会波及到许多其他的模块，这就是灵活性。灵活性其实就是“过于脆弱”的属性的方面。3、可插入性：可以很容易地将一个类抽出去，同时将另外一个有同样接口的类参加进来，这就是可插入性。其实，这就是“黏度过高”的方面。软件系统的可复用性：【软件复用的利益】1、较高的生产效率；2、较高的软件质量；3、恰当使用复用可以改进系统的可维护性。【传统的复用形式】1、代码的剪贴复用；2、算法的复用；3、数据结构的复用。【面向东西设计的复用】在面向东西语言中，数据的抽象化，继续，封装和多态性使得一个系统可以在更高条理上提供可复用性。数据的抽象化和继续干系使得观点和界说可以复用；多态性使得实现和应用得到复用；而抽象化和封装可以保持和促进系统的可维护性，复用的重点转移到含有宏观商业逻辑的抽象条理上。在面向东西的设计里面，可维护性复用是以设计原则和设计模式为底子的。提高系统可维护性和可复用性的设计原则1、“开一闭”原贝9（Open-ClosedPrinciple，大概OCP）；一个软件实体应该对扩展开放，对修改封闭；在设计一个模块的时候，应当使这个模块可以在不被修改的前提下被扩展。换言之，应当可以在不必修改源代码的情况下改变这个模块的行为。这个原贝实际上是对“对可变性的封闭原贝“：找到一个系统的可变因素，将之封装起来。这个原贝意昧着两点：1)一个可变性不应当散落在代码的许多角落里，而应当被封装到一个东西里面。同一种可变性的差别表象意昧着同一个继续品级结构中的具体子类。继续就当被看作是封装变革的要领，而不应当被认为是从一般的东西生成特殊东西的要领。2)一种可变性不应当与另一种可变性殽杂在一起。(所有类图的继续结构一般不会凌驾两层，否贝就意昧着将两种差别的可变性殽杂在了一起。)这个原贝是总的原贝，其它几条是这个原贝的手段和东西。2、 里氏替代原则(LiskovSubstitutionPrinciple，大概LSP)；如果对付每一个类型为T1的东西01,都有类型为T2的东西02,使得以T1界说的所有步伐P在所有的东西01都代换成02时，步伐P的行为没有变革，那么类型T2是类型T1的子类型。换言之，一个软件实体如果使用的是一个基类的话，那么一定适用于其子类，并且它底子不能察觉出基类东西和子类东西的区别。反过来代换不创建。3、 依赖倒转原贝U(DependencyInversionPrinciple，大概DIP)；要依赖于抽象，不要依赖于具体。开闭原贝是目标，而到达这一目标的手段是依赖倒转原贝。抽象条理包罗的是应用系统的商务逻辑和宏观的、对整个系统来说重要的战略性决定，是一定性的体现，那么抽象条理就应当是较为稳定的，应当是复用的重点；也应当是维护的重点；而具体条理贝含有一些次要的与实现有关的算法和逻辑，以及战术性的决定，带有相当大的偶然性选择。具体条理的代码是会经常有变更的，不能制止出现错误。4、 接口断绝原则(IntefaceSegregationPrinciple,大概ISP)；使用多个专门的接口比使用单一的总接口要好。换言之，从一个客户类的角度讲：一个类对另一个类的依赖性应当是创建在最小的接口上的。接口断绝原则与迪米特规则（下面讲到）都是对一个软件实体与其他的软件实体的通信限制。迪米特原则要求尽可能地限制通信的宽度和深度，接品断绝原则要求通信的宽度尽可能地窄。这样做的结果使一个软件系统在功效扩展历程当中，不会将修改的压力通报到其他东西。一个接口相当于剧本中的一种脚色，而此脚色在一个舞台上由哪一个演员来演则相当于接口的实现。因此，一个接口应当简朴地代表一个脚色，而不是多个脚色。如果系统涉及到多个脚色的话，那么每一个脚色都应当由一个特定的接口代表。5、 组合/聚合复用原则（Composition/AggregationPrinciple，大概CARP）；组合/聚合原则就是在一个新的东西里面使用一些已有的东西，使之成为新东西的一部门；新的东西通过向这些东西的委派到达得复用已有功效的目的。要尽量使用组合/聚合，尽量不要使用继续。6、 迪米特规则（LawofDemeter,大概LoD）；一个软件实体应当尽可能少的与其他实体产生相互作用。模块之间的交互要少。这样做的结果是当系统的功效需要扩展时，会相对更容易地做到对修改的封闭。一个东西应当对其他东西有尽可能少的了解。7、 单一职责原则（SingleResponsibilityPrinciple，大概SRP）在设计中为每种职责设计一个类，相互保持正交，互不干预干与。这个原则比力容易理解，这里不在多说。小结当我们掌握了C#的语法，当我们了解了面向东西的封装、继续、多态等特性，当我们可以用种种框架与技能构建桌面以及Web应用时，这并不意味着我们可以写出头向东西的步伐，不意味着我们可以很好的实现代码复用，弹性维护，不意味着我们可以实现在维护、扩展底子上的代码复用。使用面向东西语言开发的步伐不一定是面向东西的，使用面向历程的语言开发的步伐也不一定不是面向东西的。要想开发出一个具有可维护性和可复用性的软件系统，那是需要优秀的设计和长时间的运行才气完成的，其实我们可以视察一下，任何一个优秀的软件产物都是经过长时间的设计，运行，维护，修改等最后才成为乐成的产物，版本上也在不停的更新。权衡一个软件开发者是不是一个好的软件开发者，不是看他是否实现了软件的须要功效，而是要看你的软件在满足功效需求的情况下是否做到了复用性和可扩展性，这对付一个大型系统尤其重要。我们不要静止的看待一个软件，而一定要把软件历程放在时间轴上来视察与设计它，只有放在时间轴上经得住考验的软件系统才是乐成的。软件的复用性和可扩展性对付大型系统是须要的，我们在设计自己的软件系统时，甚至在编写代码时更需要考虑一下这样做是否遵循了系统设计的原则，是否有利于系统的可维护性和可复用性，是否到达了常说的“高内聚低耦合”呢？设计模式正是解决这一问题的王道。从下文开始我们将结合实例对付GoF23种设计模式进行一一解说。现在我们正式进入GoF23种设计模式中的创建型模式的解说中来，创建型模式主要解决东西如何创建的问题，提倡创建东西的责任和使用东西的责任分散，以到达更好对创建东西的控制的目的，创建型模式主要包罗抽象工场(AbstractFactory),制作者(Builder),工场要领(FactoryMethod)，原型(Prototype)，票据(Singleton)。这篇文章主要分为两大部门内容，在第一部门中我将介绍抽象工场模式的原型，包罗抽象工场的意图，可以解决的问题，原型代码和UML等，再结合一个生活中的小例子进行原型的说明。第二部门我会结合实际项目来报告一下抽象工场模式是如何应用的。最后我会对抽象工场模式进行一个小结。工场模式的几种形态工场模式专门卖力将大量有配合接口的类实例化。工场模式可以动态决定将哪一个类实例化，不必事先知道每次要实例化哪一个类。工场模式有以下几种形态：简朴工场(SimpleFactory)模式：又称静态工场要领模式(StaticFactoryMethodPattern)。主要是工场中提供一个静态的要领用来凭据差别的参数创建差别的抽象产物的具体实例，一般在IoC中应用比力多，例如通过反射机制和简朴工场模式可以解决依赖注入的问题。简朴工场模式不属于GOF23种设计模式，这里也就不再作过多的阐发。感兴趣的园友可以找找相关资料。工场要领(FactoryMethod)模式：又称多态性工场(PolymorphicFactory)模式或虚拟结构子(VirtualConstructor)模式。这个模式属于GoF23种设计模式之一，在背面的文章中会做详细的介绍。抽象工场(AbstractFactory)模式：又称东西箱(Kit或Toolkit)模式。这是本文的重点。抽象工场模式的原型描述:假设一个子系统需要一些产物东西，而这些产物东西又属于一个以上的产物品级结构。那么为了将消费这些产物的责任和创建这些产物东西的责任支解开来，可以引进抽象工场模式。这样的话，消费产物的一方不需要直接到场产物的创建事情，而只需要向一个公用的工场接口请求所需要的产物。

意图：抽象工场模式可以向客户端（Client指代码模式的使用者，后文类同）提供一个接口，使得客户端在不必指定产物的具体类型的情况下，创建多个产物族（ProductFamily指位于差别产物品级中，功效相关联的产物的聚集）中的产物东西。模式原型UML：抽象工场涉及到以下脚色：抽象工场（AbstractFactory）脚色：声明一个操纵聚集的接口以创建抽象产物族。具体工场（ConcreteFactory）脚色：实现创建具体产物族的抽象工场的实现。抽象产物（AbstractProduct）脚色：声明一个产物的接口。具体产物（Product）脚色：界说了一个被具体工场创建的产物东西，实现了抽象工场接口。客户端（Client）脚色：使用抽象工场和抽象产物的类。模式原型代码：usingSystem;namespaceDesignPatterns.Creational{//测试步伐classMainApp{publicstaticvoidMain(){//抽象工场1AbstractFactoryfactory1=newConcreteFactory1();Clientc1=newClient(factory1);c1.Run();//抽象工场2AbstractFactoryfactory2=newConcreteFactory2();Clientc2=newClient(factory2);c2.Run();//期待用户输入Console.Read();}}//抽象工场abstractclassAbstractFactory{publicabstractAbstractProductACreateProductA();publicabstractAbstractProductBCreateProductB();//具体工场1classConcreteFactory1:AbstractFactory{publicoverrideAbstractProductACreateProductA(){returnnewProductA1();}publicoverrideAbstractProductBCreateProductB(){returnnewProductB1();}}//具体工场2classConcreteFactory2:AbstractFactory{publicoverrideAbstractProductACreateProductA(){returnnewProductA2();}publicoverrideAbstractProductBCreateProductB(){returnnewProductB2();}}//抽象产物A,产物族中一个成员abstractclassAbstractProductA{}//抽象产物B,产物族中一个成员abstractclassAbstractProductB{publicabstractvoidInteract(AbstractProductAa);}//具体产物A1classProductA1:AbstractProductA{}//具体产物B1classProductB1:AbstractProductB{publicoverridevoidInteract(AbstractProductAa){Console.WriteLine(this.GetType().Name+"interactswith"+a.GetType().Name);}}//具体产物A2classProductA2:AbstractProductA{}//具体产物B2classProductB2:AbstractProductB{publicoverridevoidInteract(AbstractProductAa){Console.WriteLine(this.GetType().Name+"interactswith"+a.GetType().Name);}}//客户端，使用情况classClient{privateAbstractProductAAbstractProductA;privateAbstractProductBAbstractProductB;//结构，注意通过结构传入抽象工场publicClient(AbstractFactoryfactory){AbstractProductB=factory.CreateProductB();AbstractProductA=factory.CreateProductA();}publicvoidRun(){AbstractProductB.Interact(AbstractProductA);}}}输出结果为：ProductB1interactswithProductA1ProductB2interactswithProductA2生活中的实例这个生活中的实例代classMainApp{publicstaticvoidMain(){//创建非洲大陆ContinentFactoryafrica=newAfricaFactory();AnimalWorldworld=newAnimalWorld(africa);world.RunFoodChain();//创建美洲大陆ContinentFactoryamerica=newAmericaFactory();world=newAnimalWorld(america);world.RunFoodChain();//期待用户输入Console.ReadKey();}}//抽象工场abstractclassContinentFactory{//创建食草动物publicabstractHerbivoreCreateHerbivore();//创建食肉动物publicabstractCarnivoreCreateCarnivore();}//具体工场1classAfricaFactory:ContinentFactory{publicoverrideHerbivoreCreateHerbivore(){//返回牛羚returnnewWildebeest();publicoverrideCarnivoreCreateCarnivore(){//返回狮子returnnewLion();}}//具体工场2classAmericaFactory:ContinentFactory{publicoverrideHerbivoreCreateHerbivore(){//返回野牛returnnewBison();}publicoverrideCarnivoreCreateCarnivore(){//返回狼returnnewWolf();}}//抽象产物AabstractclassHerbivore{}//抽象产物BabstractclassCarnivore{//交互干系，食肉动物可以吃掉食草动物publicabstractvoidEat(Herbivoreh);//具体产物AlclassWildebeest:Herbivore{}//具体产物B1classLion:Carnivore{publicoverridevoidEat(Herbivoreh){//吃掉牛羚Console.WriteLine(this.GetType().Name+"eats"+h.GetType().Name);}}//具体产物A2classBison:Herbivore{}//具体产物B2classWolf:Carnivore{publicoverridevoidEat(Herbivoreh){//吃掉野牛Console.WriteLine(this.GetType().Name+"eats"+h.GetType().Name);//客户端classAnimalWorld{privateHerbivore_herbivore;privateCarnivore_carnivore;//通过结构器传入具体工场publicAnimalWorld(ContinentFactoryfactory){_carnivore=factory.CreateCarnivore();_herbivore=factory.CreateHerbivore();}publicvoidRunFoodChain(){_carnivore.Eat(_herbivore);}}}国日RealworldcodeusingAbstractFactoryinC#输出的结果为：LioneatsWildebeestWolfeatsBison什么情况下使用抽象工场：文献【GOF95】指出，在以下情况下应当考虑使用抽象工场模式：一个系统不应当依赖于产物类实例如何被创建、组合和表达的细节，这对付所有形态的工场模式都是重要的。2、这个系统的产物有多于一个产物族，而系统只消费其中某一个族的产物（上面这一条叫做抽象工场模式的原始用意。）3、同属于同一个产物族的产物是在一起使用的，这一约束必须在系统的设计中体现出来。4、系统提供一个产物类的库，所有的产物以同样的接口实现，从而使客户端不依赖于实现。实际项目举例现在需要创建分属于差别操纵系统的视窗构件。好比命令按钮（Button）与文本框（Text）等都是视窗构件，在UNIX系统的视窗情况和Windows操纵系统的视窗情况中，这两个构件有差别的当地体现，它们的细节也有所差别。在每一个操纵系统中，都有一个视窗构件组成构件家属。在这里就是Button和Text组成的产物族。而每一个视窗构件都组成自己的品级结构，由一个抽象脚色给出抽象的功效描述，而由具体子类给出差别操纵系统的具体实现，如下图所示。可以发明在上面的产物类图中，有两个产物的品级结构，分别是Button品级结构和Text品级结构、同时有两个产物族，也就是UNIX产物族和Windows产物族。UNIX产物族由UnixButton和UnixText产物组成；而Windows产物族由WinButton和WinText产物组成。系统对产物东西的创建需求由一个工场的品级结构满足，其中有两个具体工场脚色，即UnixFactory和WinFactory。UnixFactory东西卖力创建Unix产物族中的产物，而WinFactory东西卖力创建Windows产物族中的产物。这就是抽象工场模式的应用，抽象工场模式的解决方案如下图所示。平.WenT^TUniTTojitI心•就A«r*2^!总竺”也険巴翌j -CwtM显然，一个系统只能够在某一个操纵系统的视窗情况下运行，而不能够同时在差别的操纵系统上运行。所以，系统实际上只能消费属于同一个产物族的产物。这个案例实际上也正是抽象工场模式的起源。实现的代码如下。r~UnS-xButtcmItinfiuttonSuttonl±IHProjectcodeusingAbstractFactoryinC#输出结果为：ProjectcodeusingAbstractFactoryinC#//抽象工场起源案例ut(unix);client.Run();//创建Windows使用情况OSFactorywindows=newWinFactory();client=newClient(windows);client.Run();//期待用户输入Console.ReadKey();//抽象工场abstractclassOSFactory{//创建按钮构件publicabstractButtonCreateButton();//创建文本框构件publicabstractTextCreateText();}//具体工场1classUnixFactory:OSFactory{publicoverrideButtonCreateButton(){//返回Unix下的ButtonreturnnewUnixButton();}publicoverrideTextCreateText(){//返回Unix下的Text

returnnewUnixText();}}//具体工场2classWinFactory:OSFactory{publicoverrideButtonCreateButton(){//返回Windows下的ButtonreturnnewWinButton();publicoverrideTextCreateText(){//返回Winodws下的TextreturnnewWinText();}}//抽象产物AabstractclassButton{}//抽象产物BabstractclassText{//交互干系publicabstractvoidInteract(Buttonb);}//具体产物A1classUnixButton:Button{}//具体产物B1classUnixText:Text{publicoverridevoidInteract(Buttonb){Console.WriteLine(this.GetType().Name+"interactwith"+b.GetType().Name);}}//具体产物A2classWinButton:Button{}//具体产物B2classWinText:Text{publicoverridevoidInteract(Buttonb){Console.WriteLine(this.GetType().Name+"interactwith"+b.GetType().Name);}}//客户端classClient{privateButton_button;privateText_text;//通过结构器传入具体工场publicClient(OSFactoryfactory)_button=factory.CreateButton();_text=factory.CreateText();}publicvoidRun(){_text.Interact(_button);}}}UnixTextinteractwithUnixButtonWinTextinteractwithWinButton小结抽象工场模式是一个在实际项目中应用比力多的设计模式之一，抽象工场模式面对的问题是多个产物品级结构的系统设计，运用抽象工场模式的要害在于如果把创建产物的职责交给工场去完成，希望各人在掌握住工场模式原型的底子上尽量的考虑到应用，形成一种思维上的定势。这一篇我将向各人解说制作者(Builder)模式。在上一篇文章中我们主要学习了抽象工场(AbstractFactory)模式，抽象工场模式主要解决对差别品级结构的产物的创建事情，主要存眷的是创建哪一批产物的问题，而本文所讲的制作者模式主要是解决对付一个产物如何分部创建的问题，这是对付制作者模式的最初描述。同样，这篇文章主要分为两大部门来解说，第一部门我会对制作者模式的原型进行详细的说明，第二部门会对制作者模式如何解决具体问题进行探讨。制作者模式的原型描述：在软件系统中，有时候面临一个"庞大东西"的创建事情，其通常由各个部门的子东西用一定算法组成；由于需求的变革，这个庞大东西的各个部门经常面临着剧烈的变革，但是将它们组合到一起的算法却相对稳定。制作者模式是对东西的创建模式。制作者模式可以将一个产物的内部表象与产物的生成历程离开开来，从而可以使一个制作历程生成具有差别的内部表象的产物东西。制作者模式利用一个导演者东西和具体制作者东西一个一个地制作出所有的零件，从而制作出完整的产物东西。制作者模式将产物的结构和产物的零件制作历程对客户端隐藏起来，把对制作历程进行指挥的责任和具体制作零件的责任离开开来，到达责任分别和封装的目的。意图：将一个庞大东西的构建与其表现相分散，使得同样的构建历程可以创建差别的表现。模式原型UML：制作者模式涉及到以下脚色：1、 抽象制作者(Builder)脚色：给出一个抽象接口，以范例产物东西的各个组成身分的制作。此接口中一般至少划定两个要领，一个是创建部门的要领，例如BuilderPart,另一个是返回结果的要领，例如GetProduct，以约束具体制作者实现。2、 具体制作者(ConcreteBuilder)脚色：担当这个脚色的是与应用步伐紧密相关的一些类，它们在应用步伐的调用下创建产物的实例。这个脚色产物实现了抽象制作者接口，主要完身分部创建产物并提供产物东西的实例。3、 导演者(Director)脚色：顾名思义，就是具体指挥使用哪个具体创造者来完成产物的创建，是创建事情的调用者。但是，导演者脚色并没有产物类的具体知识，真正拥有产物类的具体知识的是具体制作者脚色。4、 产物(Product)脚色：产物脚色就是制作中的庞大东西。一般只有对付庞大东西的创建才使用制作者模式，一个系统中会出现多于一个的产物类，而这些产物类并不一定有配合的接口，可能完全不关联，这时就需要提供多套抽象和具体的制作者来完成不一致的产物的创建大概是接纳一个统一接口来标识产物，我小我私家推荐前者。请各人注意，这里的产物只是一个产物类，不存在继续干系，所以也就没有像抽象工场中的那种客户端依赖抽象的说法了。模式原型代码：国日BuilderpatterncodeinC#输出结果为：ProductParts PartAPartBProductParts PartXPartY生活中的实例：这个小例子向各人展示了一辆车是如何利用制作者模式被创建的，注意商店（这里就是导演者）是如何利用VehicleBuilders凭据一