go语言抽象工厂设计 go 抽象类( 三 )


工厂方法模式创建的产品一般都是单一性质产品,如成年超人,都是一个模样,而建造者模式创建的则是一个复合产品,它由各个部件复合而成,部件不同产品对象当然不同 。
这不是说工厂方法模式创建的对象简单,而是指它们的粒度大小不同 。一般来说,工厂方法模式的对象粒度比较粗,建造者模式的产品对象粒度比较细 。
两者的区别有了,那在具体的应用中,我们该如何选择呢?
是用工厂方法模式来创建对象,还是用建造者模式来创建对象,这完全取决于我们在做系统设计时的意图,如果需要详细关注一个产品部件的生产、安装步骤,则选择建造者 , 否则选择工厂方法模式 。
定义:为创建一组相关或相互依赖的对象提供一个接口,而且无须指定它们的具体类
抽象工厂模式的使用场景定义非常简单:一个对象族(或是一组没有任何关系的对象)都有相同的约束,则可以使用抽象工厂模式 。
通过工厂类,只要知道工厂类是谁,我就能创建出一个需要的对象
注意事项:
在抽象工厂模式的缺点中 , 我们提到抽象工厂模式的产品族扩展比较困难,但是一定要清楚,是产品族扩展困难,而不是产品等级 。
在该模式下,产品等级是非常容易扩展的 , 增加一个产品等级,只要增加一个工厂类负责新增加出来的产品生产任务即可 。
也就是说横向扩展容易,纵向扩展困难 。
抽象类AbstractCreator要增加一个方法createProductC(),然后两个实现类都要修改,想想看 , 这严重违反了开闭原则 。
抽象工厂模式允许在运行时更改吗抽象工厂模式(Abstract factory pattern)是一种软件开发设计模式 。抽象工厂模式提供了一种方式,可以将一组具有同一主题的单独的工厂封装起来 。在正常使用中 , 客户端程序需要创建抽象工厂的具体实现,然后使用抽象工厂作为接口来创建这一主题的具体对象 。客户端程序不需要知道(或关心)它从这些内部的工厂方法中获得对象的具体类型 , 因为客户端程序仅使用这些对象的通用接口 。抽象工厂模式将一组对象的实现细节与他们的一般使用分离开来 。
设计模式(三)创建型模式根据菜鸟教程的目录,我们首先来看看创建型模式 。创建型模式研究:
下面分别对创建型模式下的各种具体模式进行讲解 。
先看例子: 工厂模式 。
某功能的使用者只和接口打交道,不关心如何实现 。这种情况下,肯定有一个接口类,使用者使用接口;功能提供者继承并实现接口 。这利用了C++的多态特性 。
既然使用者只关心接口,那么没有必要把子类直接给使用者,没有必要让使用者在代码中直接new子类 。如果这样做,会把不必要的信息暴露给使用者,增加了信息的耦合 。试想 , 如果使用者在很多地方都new了子类,那么如果这些地方需要修改的话 , 怎么改?只能一个一个地方改,改完还需要编译 , 维护极其困难 。
工厂模式是指 , 针对某一功能接口,我们要新建一个工厂类,此工厂类将接口子类名称、接口子类的创建过程封装起来 , 只返回一个接口指针给接口的使用者 。接口的实现类对使用者完全透明,高度解耦 。这样可以方便地切换接口的具体实现,而不影响上层功能使用者 。拿 汽车 打比方,不管工厂生产 汽车 的流程是什么,只要是 汽车,它的驾驶方法(人机接口)都类似 。
显而易见,工厂模式在使用者和实现者之间增加了一个封装层,这正印证了计算机行业中一句名言:

推荐阅读