“学习OO好榜样”之创建类模式

阅读更多

周末再翻《Java与模式》，说说对创建类模式的一点理解。大家交流。

创建类模式，我主要关注的是Simple Factory、Factory Method、Builder这几个。
当然，其他一些模式可能更加常用，比如Singleton、Prototype，但比较简单，不涉及整体脉络，此处略去不述。

首先，说说Simple Factory。
创建类模式，都是对实例创建过程的封装。
Simple Factory，是最容易想到的封装方式，Client无需知道某类的instance是怎么弄出来的，直接跟工厂要实例就行了，而且是静态方法，调用起来也方便。此时，工厂(书中叫做Creator)挑起重担，何时创建什么实例、如何创建全部由他来操办。
当工厂的担子越来越重时，比如，产品种类猛增、各个产品实例的创建过程都比较复杂、判断创建何种产品实例的逻辑也越来越复杂，工厂的改动日趋频繁，而且严重地违反了Open-Close法则，不同产品类的创建代码互相影响，这就说明对变化的封装没有达到应用的效果，产品A的变化影响到了产品B。对Simple Factory的优化产生了Factory Method。

Factory Method。
不同产品的创建过程既然都有着各不相同的单独逻辑，很容易想到把这些各自繁衍的变化封装起来，于是，不同的产品由配套的Creator来创建实例。此时，系统更加复合Open-Cloase法则，增加了新产品，同时增加相应的Creator，他们都位于继承结构的叶子端，不影响枝干和其他兄弟叶子。
但，此时，Client就需要知道哪个产品是使用哪个Creator来获得实例的了。让Client知道得多了，并不一定是坏事，个人感觉这里的情况是更加符合接口隔离原则，获得了该原则带来的优势。

Abstract Factory。
用于产品系列，个人不是很喜欢这个模式。当然也欢迎大家讨论。该模式此处不述。

Builder。
如果某类的实例创建需要固定的几个步骤(我理解为几道工序或者几个零件)，想到将生产、组装过程分开(脱开耦合、增加可插入性)，再参考Template Method模式的思路，就产生了Builder模式。

再罗索一遍，创建类模式都是对实例创建过程的封装，不同模式适用于不同情况，使用得是否得当我觉得就是看对变化的封装做得好不好。