有感于@winter 的这个回答故提问。一直也很困惑如何避免过度设计？
除非你还在写 Java，否则设计模式真没多大用处。---- 补充几句 ----首先明确一点，这里说的“设计模式”，是“面向对象设计模式”的简称，以 GoF 书中列出的 23 个模式为代表。不要把什么都归为模式，比如 “if-then-else 模式”、“for each 模式”就不是（面向对象设计）模式。Like, the inverse,
reverse, double-back-flip pattern—whatever. Oh, you mean a loop? OK. --- Jamie Zawinski类似的，thread pool、thread-per-connection、process-per-connection、thread local storage、scoped locking、readers-writer lock 等等也不是面向对象设计模式。赞同
说的 “建议不要泛泛地讨论和学习‘设计模式’，而是具体到每一个模式。”如果你用的语言能把类型像变量一样赋值并传来传去，很多创建型模式就没用了。如果你用的语言能把函数像变量一样赋值并传来传去，很多行为模式就没用了。如果你用的语言 style 反对叠床架屋的 class hierarchy，很多结构模式就没用了。几个简单具体的代码示例：1. C# 内置了 delegate/event，Observer 模式就没用了。2. 如果你的语言的 typeof 操作符能得到 runtime type，那么 Prototype 模式就没用了。比如class Base(object):
class Derived(Base):
def clone(x):
return type(x)()
if __name__ == '__main__':
d = Derived()
print type(d)
# &class '__main__.Derived'&
c = clone(d)
print type(c)
# &class '__main__.Derived'&
b = Base()
print type(b)
# &class '__main__.Base'&
a = clone(b)
print type(a)
# &class '__main__.Base'&
3. 如果类型能像变量一样赋值和传递，Factory method 模式就没用了。比如class Base(object):
class Derived(Base):
def getCreator(ty):
def create():
obj = ty()
# initialize obj
return obj
return create
if __name__ == '__main__':
d = getCreator(Derived)
b = getCreator(Base)
print type(d())
# &class '__main__.Derived'&
print type(b())
# &class '__main__.Base'&
# 这个例子做作了一些，可以看第二个链接里的例子。
更多的例子见 4. 如果函数能像变量一样赋值和传递，Command、Strategy 等模式就没用了。5. EventHandler/ConcreteEventHandler 这种 callback API 风格在现代语言里基本绝迹，C++ 有 std::function、C# 有 delegate、连 Java 8 都有了 Lambda，更别说动态语言了。6. 有的语言有全局变量，Singleton 模式就没用了。Singleton 是最简单也最被滥用的模式。7. 有的语言有 multiple dispatch，Vistor 模式就没用了。其实 Vistor 模式一直就没啥用。
路过试答一下。 &br&&br&首先离题一下说点虚的&br&&br&其实GoF的《设计模式》一书，一共有三个层面的内容: &br&1. 指出编程开发活动中存在模式，提出总结设计模式需要关注的四要素 &名称-问题-解决方案-效果“ ，并给出描述一套模式的格式模板。&br&2. 提出了面向对象开发中”针对接口编程优于针对实现编程”，”组合优于继承”的总体设计思路 &br&3. 选取了现实开发中基于上述设计思路所形成的23种常见设计模式作为例子详细描述&br&&br&虽然第3点包括的多个具体的设计模式实例占据了最多的篇幅，但事实上第1,2点才是纲。实际上《设计模式》一书最划时代的意义，在于第1点。在此之后，出现了以设计模式的格式来组织内容的《分析模式》，《企业架构模式》，《企业集成模式》，《xUnit测试模式》，《重构》等等质量颇高的书籍&br&&br&在书中有一段我认为非常重要但很容易被忽略的话&br&&br&&blockquote&本书中涉及的设计模式&b&并不描述新的或未经证实的设计&/b&，我们只&b&收录那些在不同系统中多次使用过的成功设计&/b&。这些设计的&b&绝大部分以往并无文本记录&/b&，它们或是来源于面向对象设计者圈子里的非正式交流，或是来源于某些成功的面向对象系统的某些部分，但对&b&设计新手&/b&来说，这些东西是很难学得到的。尽管这些设计&b&不包括新的思路&/b&，但我们&b&用一种新的、便于理解的方式将其展现给读者&/b&，即：具有统一格式的、已分类编目的若干组设计模式。&/blockquote&&br&这段话的关键是：&br&&br&1. 书中的模式不是作者的发明创造或独门秘籍，而是早已存在并已经广泛使用的做法，只不过没有被系统地加以记录。换而言之，只要遵循某些原则，这些所谓模式完全可能在无意识的状态下自发出现在产品代码中。&br&&br&2. 这些模式在各种系统被多次使用。换而言之，你只要接触足够多的代码，必然会大量接触到这些模式的实际应用。只不过在看过《设计模式》一书之前，你可能意识不到这是一个成体系的设计手段。&br&&br&3. 作者认为《设计模式》这本书的价值在于对设计模式进行了有效的组织和便于理解的描述。换而言之，这本书的写作出发点是”便于理解“，并且是面向”设计新手“的。而不少初学者却恰恰觉得这本书难以理解，这说明，作者已经在保证准确性的前提下，选用了他们所认为最便于理解的描述。比本书描述更为显浅的描述，很可能会牺牲准确性（不准确的描述对于新手来说是显然是害处大于好处）。当然某些人认为是作者表达能力有限，这种事情无法求证，但我倾向于前者。&br&&br&===================================&br&&br&现在开始正题，如何正确使用设计模式，准确来说，正确使用GoF的《设计模式》一书中所涉及的23种模式。但我们不妨先考虑一个比较容易回答的问题，&b&如何避免不正确地使用设计模式。&/b&毕竟不正确地使用还不如不用，&b&你在避免不正确使用的前提下慢慢用起来，就是正确使用了&/b&。&br&&br&使用设计模式最常见走入歧途的做法是：你看了《设计模式》中某个具体模式，觉得似懂非懂，或者甚至根本没看过原书。然后去看了一些举例子打比喻的”再谈“，”妙解“，”大话“之类的东西，觉得豁然开朗。之后在开发时发现某一处非常符合你对这个模式的理解，于是开始使用。这种做法用来练手可以（也就是你明知使用这个模式未必是一个好主意，只是为了尝试在现实场景中去实现一下，练习代码并不进入最终产品代码），用来做真实的设计则往往谬以千里。&br&&br&原因很简单：设计模式是一种驾驭抽象概念的技术，而描述模式的标准格式里就包括了抽象描述，代码示例和应用场景。如果一个程序员根据这些信息还不能理解一个设计模式的话，说明他首先抽象思维尚不足以驾驭设计模式，其次在理解代码和接触应用场景方面经验不足。简单来说，&b&还未能达到“设计新手”的入门水平&/b&。在这种状态下勉强去使用设计模式，出问题是在所难免的。&br&&br&因而得出第一点：&b&如果你已经看过某个设计模式的描述，要正确使用它的最基本前提是，你能完全看懂GoF《设计模式》中对它的描述。&/b&在此之前，只看，不用。看是指看该模式的原文描述或者具体代码。特别地，不建议通过一些类比具体生活例子的方式来理解设计模式。设计模式的写作格式是经过验证，能有效地描述一个模式而又不失准确性的手段。如果你无法理解，看实际生产代码的应用场景是唯一真正有效的方法（因为设计模式本身就是从具体代码中总结出来的）。用类比的方法降低设计模式的抽象性来帮助了解没有实质的意义——即使你觉得自己懂了，你的抽象思维和开发经验还未达到能正确使用这个模式的水平。&br&&br&正如前面所言，&b&只要你对面向对象一些基本原则有充分的理解，你甚至可能在没看过《设计模式》之前就开始使用某种模式了&/b&，如果你已经达到这种程度自然能无压力看懂描述。退一步假如你还没达到这种程度，&b&既然《设计模式》中的模式非常常见，你只要有心多看代码，在现有代码中必然能接触到。通过实际应用的代码与书中的描述互相印证，要理解亦不难。&/b&再退一步，假如你接触的代码就一直没遇到 某个模式，你也一直无法自发理解某个模式，那么这个模式就对你没用，你没必要一定要找机会用。&br&&br&避免不正确使用的第二点是，避免过度设计。这里说的过度设计&b&本质上就是你为可能发生的变动支付了过多的复杂度代价。&/b&其实过度设计和设计模式没有必然的关系，只要你认定一个地方会变动，你就会考虑是否应该增加复杂度来换取灵活性。&b&设计模式只不过针对某些具体场景提供了一些效率较高的以复杂度换灵活性的手段而已。&/b&避免过度设计的关键是，你能正确评估未雨绸缪所引入的复杂度，相对于发生变动的可能性和破坏力，是否值得。&br&&br&正确评估变动的可能性和破坏力，只能依靠行业经验，属于资历问题。如果你对当前场景没有足够的经验进行评估，最好的办法就是假定它不会频繁变化，只采用普通的高内聚低耦合策略，而不需要增加额外的复杂度来提供灵活性。等到确认出现变化时，再进行重构。&br&&br&而对设计模式的认识可能会影响对复杂度的估计，不少设计模式的初学者很容易错误估计实现某个设计模式所带来的复杂度，认为灵活性随手可得。又或者下意识地寻找练手机会而忽略掉复杂性的代价。在假定程序员对某个设计模式已经充分理解的前提下，我觉得评估复杂度时至少应该考虑到这些因素：&br&1. 需要额外引入哪些新的概念。要明白一段代码涉及的概念越多，就越难理解。&br&2. 设计模式自身的实现复杂度&br&3. 一旦引入后，为了保持设计所带来的灵活性，后续开发需要注意的地方。是否能通过代码层面的限制来保证灵活性不会被破坏。&br&4. 团队中其他人对这个设计模式的理解程度&br&5. 对排错调试，代码静态分析可能造成的影响 （例如Observer模式和Visitor模式往往会打乱静态分析，难以通过阅读代码确定执行状态）&br&&br&如果能够大致准确地评估上述要素然后作出决定，我觉得即使变动最终没有发生，也算是一个合格的设计决策。真正的难点在于评估变动，这只能靠经验。还有就是每次做出设计决策后最好能跟踪总结，为下次决策积累经验。&br&&br&关于设计模式的使用暂时想到这些。&br&&br&========================&br&&br&既然题目中提到了“设计模式的荼毒”，这里也说说我认为《设计模式》一书中最大一处问题：一句看上去正确，但被后来一些读物误解并放大，在实际执行中造成最多问题的话：&br&&br&&blockquote&命名一个新的模式增加了我们的设计词汇。设计模式允许我们在较高的抽象层次上进行设计。基于一个模式词汇表，我们自己以及同事之间就可以讨论模式并在编写文档时使用它们。模式名可以帮助我们思考，便于我们与其他人交流设计思想及设计结果。&/blockquote&&br&这句对“模式名称”要素的描述的话，在很多后续书籍或文章中被引申为：&u&设计模式的一个重要作用是为团队提供了一套方便的交流手段&/u&。看上去非常正确，例如，我可以对同事说，这里需要一个Adapter；或者在代码中直接命名XXXApapter，同事们一看就知道这是什么了。交流变得非常方便——前提是，我们都看过《设计模式》并清楚关于这个设计模式的描述。使用设计模式进行交流的结果就是：&b&了解某个设计模式的人跟不了解这个设计模式的人根本无法交流。&/b&&br&&br&而交流在团队中是一种非常基础，不可或缺的东西，进一步的结果就是，&b&了解某个设计模式的人认为不了解这个设计模式的人达不到基础水平。&/b&而按照前文的分析，设计模式只不过是对已有开发手段的总结，完全有可能出现某个人的能力已经足够自发使用设计模式，只不过因为没认真看过《设计模式》这本书，而被认为达不到基础水平。&b&这造成了很多有一定编程能力的开发者对设计模式十分反感&/b&。&br&&br&再一步引申的结果是，因为设计模式变成了一种鉴别是否具有基础水平的手段，那么为了让自己看起来有基础以上水平，就必须要表现得懂设计模式——即使看不懂《设计模式》原文。这就给许多“大话”，“再谈”读物带来了市场，进而造就了一大批不是从实际开发或阅读代码中理解设计模式，在实际应用中错漏百出的初学者。
路过试答一下。 首先离题一下说点虚的其实GoF的《设计模式》一书，一共有三个层面的内容: 1. 指出编程开发活动中存在模式，提出总结设计模式需要关注的四要素 "名称-问题-解决方案-效果“ ，并给出描述一套模式的格式模板。2. 提出了面向对象开发中”针对接…
&p&设计模式是为了封装变化，让各个模块可以独立变化。精准地使用设计模式的前提是你能够精准的预测需求变更的走向。我们都知道大部分人是做不到的，所以大部分人就算精通设计模式也多少会做错点什么东西。所以这其实不怪设计模式&del&，怪产品狗&/del&。&/p&&br&&p&所以说如何避免过度设计，这就要求你深入的理解你的程序所在的领域的知识，了解用户使用你的软件是为了解决什么问题，这样你预测用户的需求才会比以前更加准确，从而避免了你使用设计模式来封装一些根本不会发生的变化，也避免了你忽视了未来会发生的变化从而发现你使用的模式根本不能适应需求的新走向。&/p&&br&&p&所以，在你满足了【知道所有设计模式为什么要被发明出来】的前提之后，剩下的其实都跟编程没关系，而跟你的领域知识和领域经验有关系。&/p&
设计模式是为了封装变化，让各个模块可以独立变化。精准地使用设计模式的前提是你能够精准的预测需求变更的走向。我们都知道大部分人是做不到的，所以大部分人就算精通设计模式也多少会做错点什么东西。所以这其实不怪设计模式&del&，怪产品狗&/del&。所以…
已有帐号？
无法登录？
社交帐号登录
优秀回答者
Linux C++程序员，muduo 网络库作者您的位置： >>
　　一、上篇回顾
　　上篇创建者模式中，我们主要讲述了创建者的几类实现方案，和创建者模式的应用的场景和特点，创建者模式适合创建复杂的对象，并且这些对象的每个组成部分的详细创建步骤可以是动态的变化的，但是每个对象的组装的过程来说可能是相对固定的或者说是对象的创建的过程是固定的，那么通过创建者模式可以很好的解决这类复杂对象的创建，而在我们的生活中或者是项目中可能会有这个方面的需求，那么使用创建者模式无疑是好的选择。
　　创建者模式中的每个对象组成部分的构建都是对象本身提供的内部方法，具体的创建者只是调用要创建的对象的内部的相应组成部分的构建方法，组织这些对象内部构建方法的执行顺序，完成对象的完整构建。当我们的客户应用程序需要调用这个创建者时，我们只需要通过指导者调用的形式，提供统一的创建者访问入口，通过构造函数注入或者配置文件的形式来完成创建者的注入。
　　二、摘要
　　本文主要是讲述创建型模式中一个比较特殊的模式-原型模式，这个模式呢，有个最大的特点是克隆一个现有的对象，这个克隆的结果有2种，一种是是浅复制，另一种是深复制，这里我们也会探讨下深复制和浅复制的原理，这样可能更方便大家理解这个原型模式的使用。我们都知道，创建型模式一般是用来创建一个新的对象，然后我们使用这个对象完成一些对象的操作，我们通过原型模式可以快速的创建一个对象而不需要提供专门的new()操作就可以快速完成对象的创建，这无疑是一种非常有效的方式，快速的创建一个新的对象。本文将会从以下几个方面进行讲述：
　　1、原型模式的使用场景和特点。
　　2、浅复制和深复制的原理。
　　3、举例说明浅复制和深复制。
　　4、原型模式的实现方案。
　　5、总结原型模式。
　　我们这里先给出一个原型模式的原理图：
　　三、本文大纲
　　a、上篇回顾。
　　b、摘要。
　　c、本文大纲。
　　d、原型模式的特点及使用场景。
　　e、深复制和浅复制。
　　f、原型模式的实现方案。
　　g、原型模式使用总结。
　　h、系列进度。
　　i、下篇预告。
　　四、原型模式的特点及使用场景
　　原型模式的主要思想是基于现有的对象克隆一个新的对象出来，一般是有对象的内部提供克隆的方法，通过该方法返回一个对象的副本，这种创建象的方式，相比我们之前说的几类创建型模式还是有区别的，之前的讲述的工厂模式与抽象工厂都是通过工厂封装具体的new操作的过程，返回一个新的对象，有的时候我们通过这样的创建工厂创建对象不值得，特别是以下的几个场景的时候，可能使用原型模式更简单也效率更高。
　　1、如果说我们的对象类型不是刚开始就能确定，而是这个类型是在运行期确定的话，那么我们通过这个类型的对象克隆出一个新的类型更容易。这个怎么理解。例如我们有的时候在处理DataTable中的记录进行筛选后，放在一个新的DataTable 中，我们知道如果说2个dataTable的架构不同，那么必须手动的显示的赋值，否则无法使用如下方式进行导入数据：
　　下面给出测试的相关代码和说明：
public class DataTableDemo{
public void CloneTest()
string cmdText = "SELECT * FROM TABLE";
DataTable dt = new DataTable();
//通过执行上面的cmdText 返回一个dataTable对象；
//这时候我们可以如下形式复制一个新的dataTable，而不用先创建一个dataTable，然后把每一列都显示的循环添加到新的 dataTable中，
//这是很大的工作量。
DataTable dt1 = dt.Clone();
//克隆一个新的对象 dt1.
#region 不采用克隆的形式复制一个新的dataTable
DataTable dt2 = new DataTable();
foreach (DataColumn column in dt.Columns)
dt2.Columns.Add(column.ColumnName);
#endregion
　　2、有的时候我们可能在实际的项目中需要一个对象在某个状态下的副本，这个前提很重要，这点怎么理解呢，例如有的时候我们需要对比一个对象过处理后的状态和处理前的状态是否发生过改变，可能我们就需要在执行某段处理之前，克隆这个对象此时状态的副本，然后等执行后的状态进行相应的对比，这样的应用在项目中也是经常会出现的。
　　假设我们有这样的需求，我们在ORM框架的设计中，经常会遇到这样的问题，我们在处理某个对象的编辑状态的时候，我们想框架给我们生成的更新数据库的SQL语句，不包含数据列没有发生变化的列，不要出现在更新语句中，这个时候，可能一个方案会是，编辑前克隆一个对象，然后等编辑后提交的时候，生成相应的语句时进行对比之前克隆的对象，看看是否数据发生变化，如果说对象的部分数据列发生变化，那么就只是把变化的数据列进行更新。
　　当然上面我只是给出了一种比较简单的，但是效率不是很高的实现方案，还有很多好的方案我就不讨论了，这里只是为了说明原型模式的可用场景。如果对上面的方式不是很理解或者看文字比较累的话，可以看下面的图，应该就比较清晰了。
　　这就是这种情况下可能原型模式有比较好的表现。
　　3、当我们在处理一些对象比较简单，并且对象之间的区别很小，可能只是很固定的几个属性不同的时候，可能我们使用原型模式更合适，例如我们生活中的彩虹的七彩的颜色，等等，我们只需要根据现有的一个颜色对象，克隆一个新的颜色对象，然后修改具体的颜色的值就可以满足要求，然后如果通过我们之前讲述的创建型工厂，抽象工厂模式等相对来说就引入新的依赖，并且复杂度也有所提高。例如我们的生活中的颜色的克隆：
　　我们都可以通过红色来克隆其他的所有颜色，只是修改相应的个别属性即可，远比创建一个新的象，然后给对象的各个属性赋值来的简单和方便，当然有的时候，如果我们并不需要基于现有的对象复制新的对象，或者我们需要的就是一个干净的空对象，那么我的首先还是工厂模式或者抽象工厂模式啦。
　　五、深复制和浅复制
　　既然我们本篇讲述了原型模式的具体应用，那么我们就必须先搞清楚深复制和浅复制，否则也没有办清楚原型模式中的具体的克隆过程和克隆出来对象的详细情况。
　　.NET Freamwork 内置的每个继承自System.Object都有保护成员方法：
// 摘要://
创建当前 System.Object 的浅表副本。//// 返回结果://
当前 System.Object 的浅表副本。[SecuritySafeCritical]protected object MemberwiseClone();
　　系统为我们内置提供了复制对象本身的方法，不过这个方法返回的是一个浅复制的对象副本，而且.NET给我提供了一个System.ICloneable的接口，我们通过实现这个接口，可以为对象提供自定义的克隆方法。
　　为了搞明白浅复制和深复制，那么我先要搞懂这2者的区别，.NET本身提供了浅复制的方法，而深复制的方法需要自己实现接口来完成。我们先来看看浅复制后的对象和对象副本的情况：
　　我们再看看看深复制的对象和对象副本的情况：
　　通过上面的描述，大家应该针对浅复制和深复制的区别有了大概的了解，那么我们再结合程序代码来析吧，可能大家会更熟悉具体的应用。我们先来看看最简单的浅复制和深复制情况，我们这里举例来说吧：
　　我们定义一个杯子类，并且简单定义杯子的几项简单的属性，具体代码如下：
/// &summary&/// 杯子类/// &/summary&public class Cup : ICloneable{
private double _
private int _
private Factory _
/// &summary&
/// &/summary&
public int Height
/// &summary&
/// &/summary&
public double RL
/// &summary&
/// 生产厂家
/// &/summary&
public Factory Factory
_factory =
#region ICloneable 成员
public object Clone()
return this.MemberwiseClone();
#endregion}
　　具体的测试代码：
class Program{
static void Main(string[] args)
Cup cup = new Cup();
cup.Height = 2;
Cup cup1 = (Cup)cup.Clone();
cup1.Height = 1;
Console.WriteLine(cup.Height == cup1.Height);
System.Threading.Thread.Sleep(10000);
　　运行结果如下：
　　综上所述，我们知道，对于值类型的成员，浅复制也是在副本中重新创建的成员，对应到内存的栈上，分配新的内存空间。那么对于引用类型则因为浅复的时候，对象和对象副本共用同一个引用对象，那么不管是在对象还是对象副本中修改了相应的引用成员了之后，那么这个引用类型的成员就会发生变化。因为2个对象指向同一个内存地址，那么任何一个修改操作都会产生改变。那么对于上面的这个类如何修改这个类的实现才能实现深复制呢？
　　将上面的Clone方法如下实现：
public object Clone(){
Cup cup = (Cup)this.MemberwiseClone();
Factory factory1 = new Factory();
factory1.FactoryName = this.Factory.FactoryN
cup.Factory = factory1;
　　这样就完成了对象的深复制，不管是值类型的成员还是引用类型的成员，这样的对象和对象副本，对任何一个成员属性的修改，都不会影响到改变对象的值。
　　六、原型模式的实现方案
&&&&& 6.1 原型模式的经典实现
　　我们先来看看原型模式的经典实现，我们这里已颜色为例来说名下经典实现吧，定义一个接口， 用来表述所有的颜色对象接口：
public interface IColorDemo{
IColorDemo Clone();
}}我们这里给出红色的具体实现代码：public class RedColor : IColorDemo{
private int
private int
private int
public int Red
return this.
this.red =
public int Green
return this.
this.green =
public int Blue
return this.
this.blue =
#region IColorDemo 成员
public IColorDemo Clone()
return (IColorDemo)this.MemberwiseClone();
#endregion}因为上面的对于颜色，都是通过RGB不同的比例配置出来的，所以我就定义了3个整形的变量，所以我这里只是演示说明。那么具体的测试代码如下：static void Main(string[] args){
IColorDemo color = new RedColor();
color.Red = 255;
IColorDemo color1 = color.Clone();
color1.Blue = 255;
Console.WriteLine(color.Blue == color1.Blue);
System.Threading.Thread.Sleep(10000);}返回的结果为false。代表对象副本的修改不会影响对象本身的状态。
&&&&&& 6.2、原型模式的其他情况
　　上面讲述了简单的浅复制的情况，那么我们来分析下深复制原型的实现吧，深复制可能考虑的情况相对来说就会比较复杂，因为有可能对象是之间有继承关系或者引用关系的时候，可能我们深复制的时候就需要注意，当然这对我们也是个考验。一般来说深复制一方面可以采用上面我给出的那种简单的深复制对象的时候的方案，还可以通过序列化的形式来进行对象的复制。下面我们来通过序列化的形式来实现原型模式吧：
　　我们先给出序列化和反序列化的帮助类：例如我们通过二进制的形式来进行序列化，我们都知道可以序列化的类必须打上标记，标识是否可以序列化，也可以在成员属性上定义。
/// &summary&/// 序列化和反序列化辅助类/// &/summary& public class SerializableHelper{
public string Serializable(object target)
using (MemoryStream stream = new MemoryStream())
new BinaryFormatter().Serialize(stream, target);
return Convert.ToBase64String(stream.ToArray());
public object Derializable(string target)
byte[] targetArray = Convert.FromBase64String(target);
using (MemoryStream stream = new MemoryStream(targetArray))
return new BinaryFormatter().Deserialize(stream);
public T Derializable&T&(string target)
return (T)Derializable(target);
}}下面给出简单的示例代码，还是使用上面的颜色对象为例。我们修改颜色类中的Clone方法：#region IColorDemo 成员public IColorDemo Clone(){
string target= SerializableHelper.Serializable(this);
return SerializableHelper.Derializable&IColorDemo&(target);}#endregion程序的测试代码如下：static void Main(string[] args){
IColorDemo color = new RedColor();
color.Red = 255;
IColorDemo color1 = color.Clone();
color1.Red = 234;
Console.WriteLine(color.Blue == color1.Blue);
System.Threading.Thread.Sleep(10000);}程序的运行结果为false，肯定二个对象是不同的，通过序列化和反序列化形成新的对象。其实只要是项目中要使用原型模式进行对象复制的情况下，都可以通过序列化的形式来进行深复制。
　　七、原型模式使用总结
　　原型模式作为创建型模式中的最特殊的一个模式，具体的创建过程，是由对象本身提供，这样我们在很多的场景下，我们可以很方便的快速的构建的对象，就像前面分析讲解的几类场景中，可能我们通过使用对象的克隆，比通过其他几类的创建型模式，效果要好的多，而且代价也小很多。打个比方，原型模式对于系统的扩展，可以做到无缝的扩展，为什么这么说呢？比如其他的创建型工厂，如果新增一个对象类型，那么我们不管是修改配置文件的方式，还是修改代码的形式，无疑我们都是需要进行修改的，对于我们大家通用的公共应用来说这无疑是危险的，那么通过原型模式，则可以解决这样的问题，因为类型本身实现这样的方法即可，但是也有一定的缺点，每个对象都实现这样的方法，无疑是很大的工作量，但是在某些特殊的环境下，或者实际的项目中，可能原型模式是好的选择。
　　Demo下载：
软件设计热门文章
软件设计最新文章