依赖关系的倒置

　　抽象不应该依赖于实现细节，实现细节应该依赖于抽象。-抽象A直接依赖于实现细节b（软件易脆，很容易需要重新编译）

　　-抽象A依赖于抽象B，实现细节b依赖于抽象B

　　动机（Motivation）

　　在软件系统中，经常面临着“某些结构复杂的对象”的创建工作；由于需求的变化，这些对象经常面临着剧烈的变化，但是它们却拥有比较稳定一致的接口。如何应对这种变化？如何向“客户程序（使用这些对象的程序）”隔离出“这些易变对象”，从而使得“依赖这些易变对象的客户程序”不随着需求改变而改变？

　　意图（Intent）

　　使用原型实例指定创建对象的种类，然后通过拷贝这些原型来创建新的对象

　　　　　　　　　　　　　　　　　　　　　　　　——《设计模式》GoF

　　结构（Structure）

　　例说Prototype应用

　　上面的代码，GameSystem依赖于具体的new的对象，如果面临对象变化，例如如果要增加一个新的角色，就要重新修改编译了。对此，我们就可以用工厂方法来改变，但是，对于每一个类型都要写一个工厂类，比较繁琐。我们也可以用抽象工厂方法，创建一组对象。但这里我们选择使用原型模式。

　　先把GameSystem里用到的类型换为抽象类型。

　　再将需要new的具体对象用参数传入，这样在GameSystem这个客户程序里面就只依赖于抽象而不依赖于具体了。具体的NormalActorA、FlyActorA等都不出现在GameSystem中。

　　应用程序

　　给抽象类增加Clone抽象方法

　　给具体类实现Clone方法

　　但有一点要注意，MemberwiseClone方法只是一种浅拷贝，它只能拷贝所有的值类型和String，如果是引用类型（例如数组），它就会只拷贝引用，而不会重新创建对象，例如对数组，就只会拷贝数组的地址。

如下图，左边是栈，右边是堆，（.NET的类都是在堆上）

　　如果想深拷贝，除了用笨办法，还可以用序列化的方式来做。首先需要把类标记为可序列化，然后将类序列化到内存，再把内存中的类反序列化，反序列化得到的对象和原来的对象一定是深拷贝。

　　在对于结构中的图，可以对应为：Client就是GameSystem，Operation方法就是Run。Prototype抽象类就对应NormalActor，ConcretePrototype即NormalActorA。

　　Prototype模式的几个要点

　　Prototype模式同样用于隔离类对象的使用者和具体类型（易变类）之间的耦合关系，它同样要求这些“易变类”拥有“稳定的接口”。Prototype模式对于“如何创建易变类的实体对象”（创建型模式除了Singleton模式以外，都是用于解决创建易变类的实体对象的问题的）采用“原型克隆”的方法来做，它使得我们可以非常灵活地动态创建“拥有某些稳定接口”的新对象——所需工作仅仅是注册一个新类的对象（即原型），然后在任何需要的地方不断地Clone。

　　Prototype模式中的Clone方法可以利用.NET中的Object类的MemberwiseClone()方法或者序列化来实现深拷贝。

　　有关创建型模式的讨论

　　Singleton模式解决的是实体对象个数的问题。除了Singleton之外，其他创建型模式解决的都是new所带来的耦合关系。

　　Factory Method，Abstract Factory，Builder都需要一个额外的工厂类来负责实例化“易变对象”，而Prototype则是通过原型（一个特殊的工厂类）来克隆“易变对象”。（其实原型就是一个特殊的工厂类，它只是把工厂和实体对象耦合在一起了）如果遇到“易变类”，起初的设计通常从Factory Method开始，当遇到更多的复杂变化时，再考虑重构为其他三种工厂模式（Abstract Factory，Builder，Prototype）。

　　一般来说，如果可以使用Factory Method，那么一定可以使用Prototype。但是Prototype的使用情况一般是在类比较容易克隆的条件之上，如果是每个类实现比较简单，都可以只用实现MemberwiseClone，没有引用类型的深拷贝，那么就更适合了。Prototype如果要实现深拷贝，还需要在每个要克隆的类上加序列化标签，这点复杂度要考虑进程序中。

it知识库：C#面向对象设计模式纵横谈：Prototype 原型模式，转载需保留来源！

郑重声明：本文版权归原作者所有，转载文章仅为传播更多信息之目的，如作者信息标记有误，请第一时间联系我们修改或删除，多谢。