原型模式
前序
这回小菜准备去应聘了 , 大鸟看了小菜的简历后感觉他都是在瞎扯 . 小菜准备了很多份相同的简历 . 于是大鸟便让小菜同学通过编写代码来实现相同的三份简历 .
不久后小菜实现了第一版的代码 .
小菜的第一版代码
#include <stdio.h>
class Resume
{
public:
Resume(char* _name) : name(_name),sex(0),age(0),timeArea(0),company(0){}
void SetPersonalInfo(char* _sex,char* _age)
{
sex = _sex;
age = _age;
}
void SetWorkExperience(char* _timeArea,char* _company)
{
timeArea = _timeArea;
company = _company;
}
void Display()
{
printf("%s %s %s\n",name,sex,age);
printf(" 工作经历 :%s %s",timeArea,company);
}
protected:
char* name;
char* sex;
char* age;
char* timeArea;
char* company;
};
int main()
{
Resume a(" 大鸟 ");
a.SetPersonalInfo(" 男 ","29");
a.SetWorkExperience("1998-2000","XX 公司 ");
Resume b(" 大鸟 ");
b.SetPersonalInfo(" 男 ","29");
b.SetWorkExperience("1998-2000","XX 公司 ");
Resume c(" 大鸟 ");
c.SetPersonalInfo(" 男 ","29");
c.SetWorkExperience("1998-2000","XX 公司 ");
a.Display();
b.Display();
c.Display();
return 0;
}
大鸟看后说到 :” 三份简历需要三次初始化 , 这样客户端的代码很麻烦 , 如果要二十份那就要二十次初始化 .”
小菜答到 :” 是的 . 如果写错了一个字那就要改二十次 .”
于是大鸟便叫小菜用原型模式重写了一遍代码 .
原型模式
通过给出一个原型对象来指明所要创建的对象的类型,然后用复制这个原型对象的方法创建出更多同类型的对象。原始模型模式允许动态的增加或减少产品类,产品类不需要非得有任何事先确定的等级结构,原型模型模式适用于任何的等级结构。缺点是每一个类都必须配备一个克隆方法。
依赖关系的倒置
抽象不应该依赖于实现细节,实现细节应该依赖于抽象。
(1)抽象A直接依赖于实现细节b(软件易脆,很容易需要重新编译)
(2)抽象A依赖于抽象B,实现细节b依赖于抽象B
动机(Motivation)
在软件系统中,经常面临着“某些结构复杂的对象”的创建工作;由于需求的变化,这些对象经常面临着剧烈的变化,但是它们却拥有比较稳定一致的接 口。如何应对这种变化?如何向“客户程序(使用这些对象的程序)”隔离出“这些易变对象”,从而使得“依赖这些易变对象的客户程序”不随着需求改变而改 变?
意图(Intent)
使用原型实例指定创建对象的种类,然后通过拷贝这些原型来创建新的对象
——《设计模式》GoF
在Spring中.深度科隆是应用广泛的。在实体模型上面有这样一个注解:@Component("lawsuitArchive") @scope("prototype"),表明在别的地方应用的时候,是引用其原型,同时Entity也要实现Cloneable接口和复写clone()方法。因为原型在初始化的时候就已经创建了一部分有价值的东西,减少容器的压力,而在别的地方,例如action中引用该对象的时候,直接可以使用@Resource(name="lawsuitArchive")引用对象,Spring会自动的装配好你想要的对象。