定 义:为创建一组相关或相互依赖的对象提供一个接口,而且无需指定他们的具体类
优 点:
1、封装性,每个产品的实现类不是高层模块要关心的,他们关心的是接口,抽象
2、产品族内的约束为非公开状态,具体的产品族内约束在工厂内实现
缺 点:抽象工厂模式的最大缺点就是产品族扩展非常困难,但是产品等级非常容易扩充
使用场景:一个对象族(或者一组没有任何关系的对象)有相同的约束,则可以使用抽象工厂模式
使用体会:其最大精华在于屏蔽不同对象的差异,对高层做到一致化
实践案例:
先来看看抽象工厂模式定义的UML图:
抽象工厂模式是工厂方法模式的升级版本,在多个业务品种、业务分类时,通过抽象工厂模式产生需要的对象是一种非常好的解决方式。下面看看抽象工厂的通用源代码:
那我们再来看看在工厂模式中设计的女娃造人的工厂模型,忽然发现没有男人和女人,那就是说产品有多样化了,每个种类的人中都有男人和女人之分,为了达到这种产品多样化变化的目的,根据抽象工厂设计原则重新设计如下:
经过以上设计以后,很明显将工厂分成了男人工厂与女人工厂,而一个工厂能够制造黑人、白人、黄种人,所以在一个产品多样化的时候,如何进行分类,如何将不同之处拿出来设计成工厂是一个比较有艺术性的活。想想我们在工厂模型中设计的买煤气吗?如果有一天科技发达了,我们的煤气不仅仅是天然气了,好包括外太空采过来的可燃陨石,还有地球两级的可燃冰,那如果继续让以前的物业来处理这个事情,就明显与职责单一化原则有冲突,所以我们根据抽象工厂模型进行抽象,设计了如下的模型:
这下好了,租户如果想要可燃冰,那么只需要对可燃冰物业说:给我教A公司的煤气过来,则我们自然会收到可燃冰煤气,这样设计是否非常的简单?但是看看这种模式的不合理之处,如果我再想增加一个D煤气公司煤气,那么我要修改很多地方,所有物业公司相关的接口以及子类都需要添加叫D公司煤气的方法。
来看看抽象工厂实现的代码: