设计模式的认识

【swifth原创】(tianbobo@gmail.com)
对每个设计模式，我们需要从以下几点考虑：
这个模式封装了什么？
（1.数据封装，2.父类、接口对子类、实现类封装，3.抽象对不同实现的封装）
怎么进行变化点/共同点分析的？
（模式中那个参与者是不变的，哪个是变化的，可以在后续扩展的）
模式如何根据责任进行划分的？
（根据责任进行划分，每个责任体对自己负责，不要按参与者、主题对象进行划分，会导致一个对象实现太多的功能，且类似的对象还需要重复实现部分重叠的功能。要保证有且仅有一次实现）。
模式表达了对象间的什么关系？
（优先使用组合，不要过度继承。继承体系不要超过3层。一般设计模式对象间的关系为两个并列的继承结构，这两个结构通过组合关联。如Bridge、Abstract Factory等，这个仅是部分模式的总结，不包括所有其他模式）
模式对应的场景是什么，为什么这个场景下用这个模式是合适的？
（用于检验我们的模式是这个场景下的最佳实践）。


创建型模式的总结：
Simple Factory：
如果产品不是很多，就用这个。把产品的创建集中到一个Factory类中。用switch语句，根据传入的创建产品的参数，创建相应的具体产品，返回该具体产品系列所属的共同的抽象类。client在使用返回的产品时不用去区分是哪个具体类。
Factory Method:
将具体产品的创建延后到具体工厂，父类只是保留一个桩。不同的具体工厂生成不同的具体产品。满足开发/封闭原则。对修改封闭，对扩充开发。为了新增一个具体的产品，相应的新增一个具体的工厂。使用抽象产品的client感觉不到变化的发生。
Abstract Factory:
Factory method创建一个产品的不同具体实现。抽象工厂创建一系列的产品。便于整体使用同一系列的产品，或者替换为新的系列的产品。如：IBM工厂和Mac工厂，分别可以产生各自系列中的CPU/MainBoard/Display等。
Builder:
该模式有三个参与者：Director、Builder抽象类、Product抽象类。Builder抽象类有一系列的build方法，负责创建Product的一部分。Director有控制器的角色，它的创建方法要求传入一个builder抽象类，然后它指导builder一步一步的创建成一个完整的Product。builder的每次build过程都会改变自己本身所包含（组合）的Product对象的状态。且builder都有一个getProduct的方法，用于返回创建完成的Product.Director在指导创建完成后，调用builder的getProduct方法，返回client创建好的Product。
和Abstract Factory有些类似。
可以结合Abstract Factory来合成一个Builder/Abstract Factory模式。这个模式的主模式是Builder。它的Director在指导创建方法时，调用Abstract Factory生成同质的系列产品，将这些产品作为builder的build方法的参数，通过builder来维护组合产品的状态，工厂生产零件。最后调用builder的getProduct完成。
Singleton:

Powered by ScribeFire.