2004-05-25
每次看设计模式这本书的时候都有着相同的感觉，上次没有真的理解，这次才是理解了，但是还差那么一点点。
人其实挺奇怪的，这些模式在编程的几年之内，无论是具体的项目中还是自己的练习中，都使用了很多，只是没有作为一种模式总结出来而已，而是以经验的形式存在于脑海之中，随意的使用，随意的忘却。
可能就是必然的学习过程吧，随意使用－－形成模式－－突破模式灵活应用。而模式在这里起着把经验持久化的作用吧，减少忘却的可能。
所以，真正的掌握模式，除了需要理解模式的表现之外，需要理解模式着力解决的问题，理解模式的缺陷和优势，才能做到最终灵活抽取各个模式之长而灵活组合之，这可能就是我在模式领域追求的无招胜有招的境界吧。
模式的核心目的大多是两种之一：重用和解耦
言归正传，还是来说说具体的模式吧：Design patterns
模式分类：构建型模式
模式一：抽象工厂(Abstract Factory)
Factory理解为对象工厂的概念，用以生成一个系列的对象组。
而Abstract Factory就是基于Factory之上的概念，目的是把多个系列的对象组抽取共性，屏蔽不同系列之间的对象的差异。
系列 motif windows
对象组
Button motifBtn wBtn
Bar motifBar wBar
Textbox motifTB wTB
class abstractFactory{
Button getButton();
Bar getBar();
Textbox getTextbox();
}
button,bar,textbox是一组对象，而我们需要实现motif,windows等不同系列风格的对象组，Abstract Factory提供的方式下，我们对于大多应用程序而言，操作的口是abstractFactory，以及Button,Bar,Textbox这些对象组，而无需具体关心是motif风格还是windows风格的，风格系列的指定只决定于实现abstractFactory的具体工厂类。
这种方法便于这种系列的增加，但是并不有利于对象组成员的增加，比如要增加一个label对象，我们就需要增加一个抽象对象Lable，还需要修改abstractFactory以及他所有的子类。
所以使用这种方法的时候，最重要的是对象组的规划设计。
模式二：生成器（builder）
生成器的概念是提供一系列的方法生成对象的不同部分，最终返回一个完整的对象，着力于解决将构造方法和构造步骤分离的问题，builder内部封装的是构建方法而不是过程。
做了这样的分离之后，再将builder做一个抽象，从而使得不同的构建方法和构建过程做到分离。
假设一个串的存储管理：
class builder(){
add(key,value);
addStr(str);
}
同样的操作集合，
add(key,value),addStr(str)
对于不同的builder,可能输出的结果就会有多种：
key=value;str
另一种可能：
value
str
模式三：工厂方法(Factory)
其实他的另一个名字更加能够说明问题（虚构造）
也就是说通过抽象类的共同方法来避免构造时的硬编码，
如：button对象有个getBtn的方法，
就可以避免写出button btn = new motifButton();这样的代码，而将这样的代码封装到了子类自身。
模式四：原型法（prototype）
就是在应用时并不是创建一个新的对象，而是从已有的对象中拷贝一个。
这种方式我在做配置池的时候用到过，每个业务程序从我的池中去拷贝一个对象，然后才进行相关的修改和应
用。
这种方式同样是动态创建类的方法，着重于解决当对象组的成员不稳定的情况，而不是多个系列的问题。
与Factory相比，他并不是每一个原型都需要一个构建子类。
缺点：clone本身实现的难度。
模式五：单件(singleton)
这种模式使用无数，就不再多说了。用于保证实例的唯一性。