该模型主要解决两个或多个对象间的怺通信的问题。（个h认ؓ该模式的思想同Observer模式的思想q是有点cM的。表面上看，他们所解决的问题类型根本不同，那ؓ什么我会这么认ZQ后面再说明Q。按理说Q各对象间的通信假如QObjA与ObjB要进行通信。方法有好多U。比如：可以在它们内部各存一份对方的引用。在一方变动时Q调用另一方进行同步即可。但实如果pȝ大而复杂时Q这显C的不那么清晰。因此，希望中间会有个调停者。Mediator模式因此而生。此ӞObjA与ObjB内部只存Z份Mediator(MediatorObj)对象的引用。在对象变动Ӟ只需调用MediatorObj的相x口，通知其他对象需要同步更新即可。因此，对ObjA或ObjB或其他的M对象来说Q它们有可能Ҏ不知道还有其他的对象存在。（如：ObjA可能不知道ObjB的存在。）但通过MediatorObj对象Q却辑ֈ了ObjA与ObjB的同步作用。（现在想下Q是不是与Observer模式有点cMQ因为，如果在Observer模式的实CQ抽象出一个IObserverable来。那通过IObserverable对象Q可以通知所有View的更斎ͼ?br />
class CClassA;
class CClassB;
class CMediator
{
public:
CMediator(){}
CMediator(CClassA* pObjA, CClassB* pObjB)
{
this->m_pObjA = pObjA;
this->m_pObjB = pObjB;
}
void DoSyncFromAToB(void)
{
this->m_pObjB->xxx
}
void DoSyncFromBToA(void)
{
this->m_pObjA->xxx
}
private:
CClassA* m_pObjA;
CClassB* m_pObjB;
};
class CClassA
{
public:
CClassA(){}
CClassA(CMediator* pMediator)
{
this->m_pMediator = pMediator;
}
void DoAction(void)
{
// do some work here
// 通知其他对象Q需要同?/span>
this->m_pMediator->DoSyncFromAToB();
}
private:
CMediator* m_pMediator;
};
class CClassB
{
public:
CClassB(){}
CClassB(CMediator* pMediator)
{
this->m_pMediator = pMediator;
}
void DoAction(void)
{
// do some work here
// 通知其他对象Q需要同?/span>
this->m_pMediator->DoSyncFromBToA();
}
private:
CMediator* m_pMediator;
};
]]>
该模式的出现Q主要是Z让用h?#8220;撤销”的操作。好l用h个恢复先前状态的权力。其主要思想是对象（假设其类型ؓQClassAQ的先前状态记录v来（当然自己得管理好Q。在需要时Q用此恢复。根据此思\Q当然实现方法就多种多样。下面参考设计模式资料中的c++代码。（觉得此代码设计还是挺有道理的。因为对MementocL_除了ClassA的对象外Q其他类型的对象都不需要，且也不应该能讉K到。因此，在具体实CQ它用了友元的技术）?
class COperationsMemento
{
//其实更强的，可以该c设计成。可以维护一l状态的。这P可以支?br /> //L恢复到先前的WNU状态。就好似photoshop的层的那L撤销?br /> //明思想Q此暂时只维护一个状态?/span>
private:
State GetState(void)
{
return this->_sta;
}
void SetState(const State& state)
{
this->_sta = state;
}
// some code here
private:
State _sta;
};
class COperationSteps
{
public:
friend class COperationsMemento;
COperationSteps()
{
this->m_pMemento = NULL;
this->_sta = "normal";
}
COperationSteps(COperationsMemento* pMemento)
{
this->m_pMemento = pMemento;
this->_sta = "normal";
}
virtual ~COperationSteps()
{
if (m_pMemento != NULL)
{
delete m_pMemento;
m_pMemento = NULL;
}
}
//存储状?卻I保存状?
void SaveState(void)
{
if (m_pMemento == NULL)
{
m_pMemento = new COperationsMemento();
}
m_pMemento->SetState(this->_sta);
}
//恢复状?/span>
void RestoreState(COperationsMemento* pMemento = NULL)
{
if (pMemento != NULL)
{
this->_sta = pMemento->GetState();
}
else
{
this->_sta = m_pMemento->GetState();
}
}
private:
COperationsMemento* m_pMemento; //需要维护，因ؓ该状态，是自q有的
State _sta;
};
]]>
class Strategy2
{
3
public:4
//5
virtual void Func1(void) = 0;6
virtual void Func2(void) = 0;//q两个接口只是示?br /> 7 // some other interfaces here8
};9
10
class Sub1 : Strategy11
{12
public:13
void Func1(void)14
{
15
// do something16
}17
void Func2(void)18
{19
// do something20
}21
};22
23
class Sub2 : Strategy24
{25
public:26
void Func1(void)27
{28
// do something29
}30
void Func2(void)31
{32
// do something33
}34
};35
36
class Strategy;37
//{略cȝ?/span>38
class Context39
{40
public:41
Context(const Strategy* pStrategyObj) : m_pStrategyObj(pStrategyObj) {}42
// 43
// 逻辑接口DoAction44
void DoAction(void)45
{46
if (NULL != m_pStragegyObj)47
{48
m_pStrategyObj->Func1();49
m_pStrategyObj->Func2();50
// 51
}52
}53
};
注意Q设计模式中Q更提倡优先用组合，而非l承。详l原因，也可以从以上模式比较得出?br />
]]>
class LogicalAbstractClass2
{3
public:4
// some code here5
// 逻辑接口16
virtual void Logical1() = 0;7
// 逻辑接口28
virtual bool Logical2() = 0;9
// some other logical interfaces10
};11
12
class SubClassA : public LogicalAbstractClass13
{14
public:15
void Logical1(){ }16
bool Logical2(){ return true/false; }17
};18
19
class SubClassB : public LogicalAbstractClass20
{21
public:22
void Logical1(){ }23
bool Logical2(){ return true/false; }24
};25
26
int main(int argc, char* argc[])27
{28
LogicalAbstractClass* pA = NULL;29
LogicalAbstractClass* pB = NULL;30
pA = new SubClassA;31
pB = new SubClassB;32
33
delete pB;34
delete pA;35
}补充QDelphi的codeCZ׃l了。一个道理。懂得思想Q所有语a通用?img src ="http://www.shnenglu.com/Tongy0/aggbug/148524.html" width = "1" height = "1" />
]]>
在现有的对象中，暂时没有办法处理。同Ӟ却发玎ͼ该功能，其实另一模块的对象却可以处理的了。因此，希望能够在不修改原
有操作及pȝl构的情况下Q就自然而然地将该功能实现出来。此Ӟ可以用Adapter来处理之。（注：在此Q我们强调的是不
M改原有系l的l构的情况下Q?br /> ׃q问题，Adapter模式有两U解x法。一U是通过对象适配来解冟뀂另一U是通过c适配来解冟뀂所谓的对象适配Q指
的是Q通过引入h我们需要功能接口的对象Q设cMؓXQ，在实现处理过E中Q我们用的是X的功能接口，以此来达到我们的需求?br />而类适配Q则指的是，产生一个新c，让该新类Q承自Xc，则自Ӟ该新cd会有了X的相x口。下面看下，q两U适配的代码?/p>
对象适配
class X
{
public:
...
virtual func(...);
};
class ObjAdapterObject : public ...
{
public:
void func(...)
{
if (m_pXObj != NULL)
m_pXObj->func(...);
}
private:
X* m_pXObj;
};
c适配
class X的声明及定义同上?/p>
class ClassAdapterObject: public X, public ...
{
public:
...
};
以下调用׃写了Q你懂得的?/p>
QFacade模式Q门面模式与Proxy模式其实q是有点怼的。也是主要实CU功能的装。Facade模式Q主要是几个有相关性的功能操作Q封装到一Pq一的接口提供?br />使用Ӟ通过该接口即可完成所有相关的功能。此有个好处Q就是提高解耦性与增加高聚性。实CQ查处问题也相对方便?br /> 单，代码不就l了?/p>
十：Flyweight模式Q即Qn元模式）
说的直观点，Flyweight模式其实是实现一个对象缓存池。取对象Q优先从该池中取出。而它们的区别在于Q从前者中取东西时Q如果不存在。则可以C生一个，q返回?br />而从后者中取时Q存在就q回Q不存在Q就q回为空?br /> ׃面的解释Q不难想象，该模式的实现Q?br />class Flyweight
{
public:
...
};
class SubFlyweightObjX : public Flyweight
{
...
};
class SubFlyweightObjY : public Flyweight
{
...
};
//Flyweightcȝl构
class FlyweightBuffFactory
{
public:
Flyweight* GetFlyweight(...condition...)
{
for (vector<Flyweight* >::iterator iter = m_vBuffer.begin(); iter != m_vBuffer.end(); iter++)
{
if (iter.xxx = condition)
return (Flyweight*)iter;//注：如果此句不行用这句：return (Flyweight*)(&(*iter));
}
Flyweight* pReturn = new xxx;
m_vBuffer.push_back(pReturn);
return pReturn;
}
private:
vector<Flyweight* > m_vBuffer;
};
]]>
代理模式Ӟ思想倒类g装的概c主要是某功能操作通过另一对象Q来全权处理。对
被代理的对象Q它不管你是如何处理。它只要l果。比如：Ҏ据的提取。原本可能要l过N个对象共
同配合，最l取得数据。此Ӟ可以用一个代理对象，来全权处理之。又比如_我们上网Q打开|页Q?br />可以通过windows的网l功能模块，去解析，q最l打开|页。同时也可以通过代理Q解析ƈ最l打开|?br />c?/p>
下面是参考代?br />class Subject
{
public:
virtual void Request() = 0;
protected:
Subject(){}
};
class ImplSubject
{
public:
virtual void Request(){ //....}
};
class Proxy
{
public:
Proxy(){}
Proxy(Subject* sub){m_pSub = sub;}
private:
Subject* m_pSub;
void Request(){ m_pSub->Request();}
};
int main(int argc, char* argv[])
{
Subject* sub = new ImplSubject();
Proxy* p = new Proxy(sub);
p->Request();
return 0;
}
]]>
(?)假设有这L一个问题存在（其实现实开发中Q非常经帔R刎ͼQ基cBasicClassX有N个的zcR因为它们没有功能接口void UnknowFunction(void);
按正常的。我们的处理ҎQ（1Q?可以通过直接修改BasicClassX基类Q在此添加virtual void UnknowFunction(void);虚接口ƈ实现Q然后所有derived
class中均可见。（2Q?又或是在BasicClassX基类Q添加了U虚接口Q然后在具体某派生类中进行了实现。在实现使用中，用该derived class来处理?br /> (?)但这样做会有q样的问题存在：a) 会有可能让承的深度Q变的很深。系l的cd变的很多Q很复杂。b) cȝl构也将变的复杂化。（因ؓ?br />在是增加个接口，以后要是又有其他的接口功能需要添加了Q？Q） c) 无Ş中，会加重基cȝ负担。因为必d保证扩展该接口，否则基类看不到该?br />口?br /> (?)Z解决上面的问题。Decorator模式可以帮助我们很L地解冟뀂我们实C个DecoratorcR该c，只要引用一个BasicClassX指针对象卛_?br />然后在DecoratorcMQ扩展功能接口，q样Q新扩展的功能就与BasicClassX的相关类Q无M关系。只是在BasicClassX相关c需要该扩展接口的地方，
使用DecoratorcL处理卛_。就相当于BasicClassX的对象（或是它的derived class objectQ委托Decorator来实现处理一栗但又同时像是将BasicClassX
对象与Decorator对象q行l合在一起用。从而达到新接口的扩展作用。Decorator模式是q么回事?br /> 下面要提gDecoratorcȝ设计
SubClassA : BasicClassX;
SubClassB : BasicClassX;
SubClassC : SubClassA;
...
SubClassN : ... : BasicClassX;
class Decorator : BasicClassX
{
public:
Decorator(BasicClassX* pBObj){m_pBOjb = pBObj;}
void DoOperate(void)
{
m_pBObj->DoOperator();
// do new interface
this->DoNewInterfaceFunction();
}
//new extened interface function
void DoNewInterfaceFunction(void){//do something...}
// new extened other interface function
...
//write down other code in here you knowned.
...
private:
BasicClassX* m_pBObj;
}
个h认ؓQDecorator模式Q你说它有用。它实有用。说它没用。其实它也没用。ؓ啥这栯了？因ؓ它完全可以通过Q承，或者直接修改原有的cMpL
实现。但它的存在Q也实会让pȝ的思\清晰些。至代码相对不会那么ؕ?/p>
八：Composite模式Q即Q复合模式）
复合模式旨在递归处理Q{化ؓ一U顺序处理。明昑֜Q递归处理Q相对较耗资源。也相对较ؓ抽象些。而用一个Compositecd象来转化处理
递归处理。将昑־直观些。它与Decorator模式的区别是QComposite模式Q旨在构造一个类。这个类Q将原本是递归l织的树状结构，转换为直观地转化?br />序l构。即Q它重要于{化表现。而Decorator模式Q即Q修饰模式）Q其重要化管理原本系l类体系l构。不至于类l承体系来深。同Ӟ?br />至于让原本设计好的类Q越来越复杂化。同时又可以为原本类体系d新的功能Q即Q书上所q的新的职责Q?/p>
下面要看下该模式的代码结构：
class ClassNode
{
public:
//写下构造函数等
...
public:
virtual void Operation(void);
virtual void Add(ClassNode* pNode);
virtual void Remove(ClassNode* pNode);
virtual ClassNode* GetNode(int iIndex);
}
//Compositec?br />class Composite : public ClassNode
{
public:
typedef vector<ClassNode* > NODELISTVEC;
public:
void Operation(void)
{
for (NODELISTVEC::iterator iter = m_vNodeList.begin(); iter != m_vNodeList.end(); iter++)
iter->Operation();
}
void Add(ClassNode* pNode){//do something...}
void Remove(ClassNode* pNode){//do something...}
ClassNode* GetNode(int iIndex){//do something...}
private:
NODELISTVEC m_vNodeList;
}
//调用
int main(int argc, char* argv[])
{
Composite* MyCompositeForNodes = new ...;
ClassNode* xxx = new ...;//创徏节点。当然这里只是ؓ了演C，所以只创徏一个节炏V一|有可能有N个节炏V?br /> MyCom,positeForNodes.Add(xxx );
...
MyCompositeForNodes.Operation();
}
//个h认ؓQ该模式Q很怪啊。。因为通过q样转换后，原本的父子关pd被破坏掉了?br />//如果有大侠理解的q话，Q还请不吝补充下。。不盛感Ȁ?/p>
七：Decorator模式Q即Q装饰模式）
(?)假设有这L一个问题存在（其实现实开发中Q非常经帔R刎ͼQ基cBasicClassX有N个的zcR因为它们没有功能接口void UnknowFunction(void);
按正常的。我们的处理ҎQ（1Q?可以通过直接修改BasicClassX基类Q在此添加virtual void UnknowFunction(void);虚接口ƈ实现Q然后所有derived
class中均可见。（2Q?又或是在BasicClassX基类Q添加了U虚接口Q然后在具体某派生类中进行了实现。在实现使用中，用该derived class来处理?br /> (?)但这样做会有q样的问题存在：a) 会有可能让承的深度Q变的很深。系l的cd变的很多Q很复杂。b) cȝl构也将变的复杂化。（因ؓ?br />在是增加个接口，以后要是又有其他的接口功能需要添加了Q？Q） c) 无Ş中，会加重基cȝ负担。因为必d保证扩展该接口，否则基类看不到该?br />口?br /> (?)Z解决上面的问题。Decorator模式可以帮助我们很L地解冟뀂我们实C个DecoratorcR该c，只要引用一个BasicClassX指针对象卛_?br />然后在DecoratorcMQ扩展功能接口，q样Q新扩展的功能就与BasicClassX的相关类Q无M关系。只是在BasicClassX相关c需要该扩展接口的地方，
使用DecoratorcL处理卛_。就相当于BasicClassX的对象（或是它的derived class objectQ委托Decorator来实现处理一栗但又同时像是将BasicClassX
对象与Decorator对象q行l合在一起用。从而达到新接口的扩展作用。Decorator模式是q么回事?br /> 下面要提gDecoratorcȝ设计
SubClassA : BasicClassX;
SubClassB : BasicClassX;
SubClassC : SubClassA;
...
SubClassN : ... : BasicClassX;
class Decorator : BasicClassX
{
public:
Decorator(BasicClassX* pBObj){m_pBOjb = pBObj;}
void DoOperate(void)
{
m_pBObj->DoOperator();
// do new interface
this->DoNewInterfaceFunction();
}
//new extened interface function
void DoNewInterfaceFunction(void){//do something...}
// new extened other interface function
...
//write down other code in here you knowned.
...
private:
BasicClassX* m_pBObj;
}
个h认ؓQDecorator模式Q你说它有用。它实有用。说它没用。其实它也没用。ؓ啥这栯了？因ؓ它完全可以通过Q承，或者直接修改原有的cMpL
实现。但它的存在Q也实会让pȝ的思\清晰些。至代码相对不会那么ؕ?/p>
六：Bridge模式Q即Q桥接模式）
讲之前，先声明：׃本h电脑不是很好Q没法装上vc环境q行。因此以下代码，仅是手工输入Q在环境中未必能~译通过?br>但以下，仅仅只是介绍一U思想。仅供参考。同Ӟ如果说明有误之处Q欢q指正。另外，则于一ơ性手工输入下面那么多东东Q确?br>不容易，所以Delphi的具体实现。就不在此列出。如有兴用Delphi实现的朋友，也可以找本h交流Q本人盛感荣q?br>Q当然如果是C++的朋友也同样、甚x加欢q）
看了q么多次的桥接模式，q次ȝ明白了。要想理解桥接模式，个h认ؓQ还是有必要同抽象及其实现进行一下比较?br> 1) 抽象及实现。我怿Q跟不同的h说话Q都会有诀H在里头。同是coderQ相信，最默契的沟通，q是code吧。我们来看下抽象及其实现的代码?br>//抽象基类声明
class AbstractClassX
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}
//AbstractClassX的具体实?ClassXImplX1
class ClassXImplX1 : public AbstractClassX
{
....
public:
void DoSomething(void){ // do something with method 1... }
}
//AbstractClassX的具体实?ClassXImplX2
class ClassXImplX2 : public AbstractClassX
{
....
public:
void DoSomething(void){ // do something with method 2... }
}
在实际应用中Q我们用的是抽象cR而实际上实例化的Q却是某具体子类。这U实现被我们多数人所使用。而它实际上解决的只是q么一c问题，卻I同一行ؓ的不同表现。当
然大多数需求，用此可以了?br> 但现在假如说有这么一U情况：假如_上面的处理仅仅只适用于^台AQ而用户却希望同时Q它也要能够在^台B上也能够一L操作。那当如何？
很明昄Q此U需要，q不是行Z的需求，因ؓ不论是在q_A上还是^台B上，都要执行相同的操作。而且表示也是一L。该需要的实现。实际上是需要我们重新封装个抽象层，
来专门处理^台B上的该行为。而实际的实现Q却q是跟^台A上的一栗其实我们仔l一惟뀂其实^台A了的抽象Q即QAbstractClassXQ与q_B上的抽象Q假如ؓQAbstractClassYQ，
其实它们是类似的。因为需要处理的功能一栗因此，我们想Q如果将q种抽象与实现具体分d来。在抽象中，留个具体实现的抽象引用（此其实就是该模式所指的Bridge----卻I?br>通过该桥Q将抽象与具体的实现q接h。因此，我想该模式的名称是因此得来的吧Q。那栗抽象可以不受限制的扩展Q实C同样可以不受限制的扩展。这Ppȝ的框架就不需?br>更改Q其不妙哉？Q因此就有了如下的code
//******************************************************************
//* 抽象声明及抽象部分的实现
//******************************************************************
//抽象的抽象基cd?br>class AbstractClass
{
private:
//xxx
protected:
AbstractImpl* m_pAIObj; //具体的抽象实现的抽象对象Q这话很ao口，但理解了q话Q也q解了该模式。可以大a不惭地说Q该模式的秘密就在这句话上）
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}
//q_A上的抽象的具体实?注意Q此实现子类Q是针对抽象?
class AbstractClassA : public AbstractClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { m_pAIObj.DoSomething(); }
//xxx
}
//q_B上的抽象的具体实?注意Q此实现子类Q是针对抽象?
class AbstractClassB : public AbstractClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { m_pAIObj.DoSomething(); }
//xxx
}
//******************************************************************
//* 实现的抽象声明及其实?br>//******************************************************************
//实现部分的抽象基cd?br>class AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) = 0;
//xxx
}
//具体法1的具体实?br>class ImplX : public AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { // do something... }
//xxx
}
//具体法1的具体实?br>class ImplY : public AbstractImplClass
{
private:
//xxx
protected:
//xxx
public:
//xxx
void DoSomething(void) { // do something... }
//xxx
}
//******************************************************************
//* 实际应用斚w
//******************************************************************
int main(int argc, char* argv[])
{
AbstractImplClass* pImplObj = new ImplX();//或new ImplY();{等?br> //下面注意下：因ؓ上面的代码中Q本Zؓ了简写，q没有明写出抽象部分的具体构造函数?br> //怿Q是E序员，看完下面q行都懂得，上面的抽象部分的声明Q应该声明一个什么样?br> //构造函数吧?br> AbstractClass* pAbstractObj = new AbstractClassA(pImplObj);//或new AbstractClassB(pImplObj);{等?/p>
//do other something...
//在此补充一点：有上面的设计Q系l的框架都无需修改。不论是实现的具体算法改变了Q还?br> //抽象的需求变动。程序都无需要修Ҏ架代码，Q仅仅只需要写个具体的实现c（不管是实现的实现c，q是
//抽象的实现类Q即可。这是桥接模式?br>}
]]>
五：Prototype模式Q即Q原型模式）
此模式其实很单，主要是通过“克隆”的技术，来生出新的对象来。其与抽象工厂模式以及Builder模式的区别是Q抽象工厂模式式Q主要用来生多个有怺依赖关系的对象的创徏?br>而构建模式则主要用来处理一个复杂模块的一步步构徏工作。原型模式，则注重通过自nQ来复制Z份与自n一L实例对象来。原型本w也有点cM一个抽象工厂?br> 原型模式常用的接口一般有QClone(); Asign(); q有拯构造函数。（对Delphi来说Q主要还是前两种ҎQ?/p>
前面一至五Q可被归UؓQ创建型模式
]]>
三：Singleton模式Q单实例模式Q?/p>
思义Q即单例模式。其主要思想是在项目中Q仅创徏一个实例对象。该对象的抽象，除了通过指定的获取实例接口外Q再没其他办法可以初始化?br>此可以保证整个系l生命周期内Q仅会有一个实例存在。可以想象一下，它是可以与先前说的工厂模式或抽象工厂模式l合使用的。因Z般来_工厂可能只会
有一个（臛_ҎU逻辑处理来说是这LQ?br> 在C++中，实现单例模式Q相Ҏ较直观及合理。将该实例定义成static成员卛_。ƈ提供获取及释放该成员的接口。而在delphi中，Q就本来的了解来_
gq没有直观的静态成员这一说法。但可以定义一个全局变量Qƈ提供获取与释攑֏量的接口来模拟。（但，毕竟没办法同cd的实例被创徏出来Q所以最好要?br>详细注释说明。告知其他组员，此ؓ单实例）
参考的c++实现Q?br> class CA
{
private:
CA(){}
private:
static CA* m_pAObj;
public:
virtual ~CA(){}
static CA* GetAObj(void)
{
if (m_pAObj == NULL)
m_pAObj = new CA();
return m_pAObj;
}
static void SafeReleaseAObj(void)
{
if (m_pAObj != NULL)
delete m_pAObj;
m_pAObj = NULL;
}
};
static CA* CA::m_pAObj = NULL;
参考的Delphi实现Q?br> unit xxx
interface
uses
xxx,...,yyy;
type
TMyClass = class
//xxxx
end;
var
gAObj: TMyClass;//此ؓ全局的单实例对象?br> function GetAObj: TMyClass;
procedure SafeReleaseAObj;
implemention//q个单词忘了是不是这么写。反应是实现的那个单词。?br> procedure SafeReleaseAObj;
begin
if Assigned(gAObj) then
FreeAndNil(gAObj);
end;
funciton GetAObj: TMyClass;
begin
if not Assigned(gAObj) then
gAObj = TMyClass.Create;
Result := gAObj;
end;
//说明Q以上仅是时写的，q未在程序中~译试。但思\肯定不会错。可供参考用?br>
四：Builder模式Q即Q构建模式）
往往在实际项目的开发过E中会发玎ͼ某些模块的功能过于复杂。此Ӟ我们自然׃惛_其q行q一步的划分。如Q细分成DA,DB,...,DN。然后由该模块的某个理角色q行协调q作?br>q样QBuilder模式可用在此设计上。其思想Q就是将复杂问题q一步细化?/p>
设计模式其实只是一U程序设计的思想准则。通过该思想准则来指导我们的E序开发行为，量让开发的E序更加E_、高效、思\清晰、少bug......
开发一E序目Q往往q不只限于单一C用某一模式。往往会多U模式同时用?/p>
其实Q设计模式在具体目中的应用开发中。要说要用xxx/xxx模式来搭框架开发等{，q些都是不对的。因Z为，设计模式的应用，是随着目?br>不同而定的。因Z同的目有着不同的解x案。而不同的解决ҎQ将军_着Q需要用哪xxx/哪xxx模式来处理会比较好，此时才能_定了项?br>的框架等{?br> 比如_本来需要开发一个本地资源管理的目。如果你一开始就l它定了一定要用单实例模式来搭框架实现。那我们׃明白了这个实例，在框架中Q?br>到底它应该是什么。反q来Q正常的Q我们应该根据这个项目的需要来定应该用到的模式。就拿该例子来说。我们可以对资源斚wQ用抽象工栈模?br>在资源与展现及其处理斚wQ我们可以应用观察模式（卻I所谓的observer模式Q。如此一来，我很明确了，该系l大|的框架。这正应了刚开始的一句话
Q设计模式只是一U程序设计的思想准则Q它只是用来指导E序开发的行ؓ?/p>
当然x得设计模式的东东Q确实还是离不开面向对象Q的思想Q。对oo思想更解的越深刻Q学赯计模式的相对越LQ也更解的会更深MQ当Ӟ
学习它将是个不断q代的过E的Q。反q来Q对设计模式理解的越深刻Q对oo的理解及应用与设计，也将大大有益?/p>
一QFactory模式Q工厂模式）
所谓的Factory模式Q即Q它能类似工厂一P不断C生（卻I创徏Q?#8220;产品”出来。但它所创徏出来的那?#8220;产品”Q一般是抽象cȝ产品。D例：
假如有抽象类AbstractBasicClass。我们要想用它Q必d有它的实现类。按正常来说Q我们可以直接通过其具体的子类实例化一个品出来。但q样?br>有个问题Q当AbstractBasicClass拥有NU不同的实现子类Ӟ那我们到底要使用哪种具体子类来实例化Qƈ且，各个不同的具体实现子cȝ命名Q也是
个可怕的问题。因此这Ll护变得十分复杂。而Factory的设计就可以h很好的一个维护作用。其实Factory模式的设计，q有一个好处，是使得实例
化得C推迟Q到了后?---一般指执行期）?/p>
二：AbstractFactory模式Q抽象工厂模式）
上面Factory模式Q其实针对的是一cȝ的情况，卻I处理的上上面的AbstractBasicClassq一cȝ的情c而实际项目中Q却往往需要处理NU的q样抽象cR?br>的情c此Ӟ我们这NU类的品创建都归到一个Factory中时Q此时的Factory即ؓ一个AbstractFactory了。因此说QFactory与AbstractFactory只不q?br>是处理的cdcȝ个数差异|了。其思想是类似的?br> 但一般来说AbstractFactory所产生出来的种抽象c，其实它们之间Q一般来_或多或少Q会是有一定的关系的。比如：一个Abstractfactory产生Z?br>抽象cȝ产品A和B。则A可能需要B的某些功能，反之cM?/p>
结QFactory与AbstractFactory的设计，最l的目的都只是ؓ了用系l抽象类的维护更加简单些?/p>