再来介绍一下抽象工厂模式(Abstact Factory Pattern),也是创建型模式之一,上篇博客主要介绍了工厂方法模式。抽象工厂模式和工厂方法模式稍有区别。工厂方法模式中工厂类生产出来的产品都是具体的,也就是说每个工厂都会生产某一种具体的产品,但是如果工厂类中所生产出来的产品是多种多样的,工厂方法模式也就不再适用了,就要使用抽象工厂模式了。
抽象工厂模式的起源或者最早的应用,是对不同操作系统的图形化解决方案,比如在不同操作系统中的按钮和文字框的不同处理,展示效果也不一样,对于每一个操作系统,其本身构成一个工厂类,而按钮与文字框控件构成一个产品类,两种产品类两种变化,各自有自己的特性,比如 Windows,Unix 和 Mac OS 下的 Button 和 Text 等。所以据此,我们可以初步构建框架:
然后对于 Windows 系统来说需要生成的是 WindowsButton 和 WindowsText 产品类对象,其他两个系统一样也需要对应的对象。为了达到“为创建一组相关或者是相互依赖的对象提供一个接口,而不需要指定它们的具体类”的松散耦合原则,这时使用抽象工厂模式就非常契合。
PS:对技术感兴趣的同鞋加群544645972一起交流。
java/android 设计模式学习笔记目录
抽象工厂模式(Abstact Factory Pattern)提供一个接口,用于创建相关或依赖对象的家族,而不需要明确指明具体类。
和工厂方法模式一样,抽象工厂模式依然符合“针对抽象编程,不针对具体类编程”的原则,将客户端和具体类解耦,增加扩展性,契合设计模式中的 依赖倒置原则 和 里氏替换原则 。
我们来看看抽象工厂模式的 uml 类图:
虽然抽象工厂模式的类繁多,但是主要还是分为 4 类:
这里用的是一个实例的 uml 类图,对应的抽象工厂模式的 uml 类图只要把其中的角色换一个名字就可以了,是一样的。
我们直接根据上面的 uml 类图来构建我们的图形系统,Button 和 Text 的角色是产品类,他们对应都有 3 个实现的产品子类;Windows , Unix 和 MacOS 这几个系统应该为具体的工厂类:
产品类主要是 IButton 接口和其实现子类,IText 接口和其实现子类。IButton 接口和其子类:
IButton.class
public interface IButton { void show(); }
public class WindowsButton implements IButton { @Override public void show() { Log.e("show", "this is a Windows button"); } }
public class UnixButton implements IButton{ @Override public void show() { Log.e("show", "this is a Unix button"); } }
public class MacOSButton implements IButton{ @Override public void show() { Log.e("show", "this is a MacOS button"); } }
IText 接口和其实现子类:
IText.class
public interface IText { void show(); }
public class WindowsText implements IText{ @Override public void show() { Log.e("show", "this is a Windows text"); } }
public class UnixText implements IText{ @Override public void show() { Log.e("show", "this is a Unix text"); } }
public class MacOSText implements IText{ @Override public void show() { Log.e("show", "this is a MacOS text"); } }
上面定义完产品的相关类之后就要定义工厂的相关类了,工厂类的作用主要是用来创建对应的两个产品种类的对象:
IFactory.class
public interface IFactory { /** * 生成对应按钮 */ IButton createButton(); /** * 生成对应文字 */ IText createText(); }
public class WindowsFactory implements IFactory { @Override public IButton createButton() { return new WindowsButton(); } @Override public IText createText() { return new WindowsText(); } }
public class UnixFactory implements IFactory{ @Override public IButton createButton() { return new UnixButton(); } @Override public IText createText() { return new UnixText(); } }
public class MacOSFactory implements IFactory{ @Override public IButton createButton() { return new MacOSButton(); } @Override public IText createText() { return new MacOSText(); } }
最后的测试程序也很简单:
@Override public void onClick(View v) { switch (v.getId()) { case R.id.btn_Windows: WindowsFactory windowsFactory = new WindowsFactory(); windowsFactory.createButton().show(); windowsFactory.createText().show(); break; case R.id.btn_Unix: UnixFactory unixFactory = new UnixFactory(); unixFactory.createButton().show(); unixFactory.createText().show(); break; case R.id.btn_MacOS: MacOSFactory macOSFactory = new MacOSFactory(); macOSFactory.createButton().show(); macOSFactory.createText().show(); break; } }
对象的日志也能够成功的打印:
抽象工厂模式在 Android 源码中的实现相对来说是比较少的,其中一个比较确切的例子是 Android 底层对 MediaPlayer 的创建,具体类图如下所示(在新的标签页中打开该图片即可):
四种 MediaPlayerFactory 分别会生成不同的 MediaPlayer 基类:StagefrightPlayer、NuPlayerDriver、MidFile 和 TestPlayerStub ,四者均继承于MediaPlayerBase 。
抽象工厂的优点有很多,一个显著的优点是分离接口与实现,客户端使用抽象工厂来创建需要的对象,它根本就不知道具体的实现是谁,客户端只是面向产品的接口编程而已,使其从具体的产品实现中解耦,同时基于接口与实现的分离,使抽象工厂模式在切换产品类时更加灵活、容易。
当然缺点也是很明显的,第一个也是最明显的就是类文件的大大增多,第二个是如果要扩展新的产品类,就需要去修改抽象工厂类的最下层接口,这就会导致所有的具体工厂类均会被修改。
其实对比一下两种模式的 uml 图,就可以发现其实工厂方法模式是潜伏在抽象工厂模式中的,抽象工厂中的每个方法都可以单独抽出来作为一个工厂方法。抽象工厂的任务是定义一个负责创建 一组 产品的接口,这个接口内的每个方法都负责创建一个具体产品,同时我们利用实现抽象工厂的子类来提供这些具体的做法,所以在抽象工厂中利用工厂方法来实现生产方法是相当自然的做法。这么一对比,可以知道抽象工厂模式比工厂模式的一个优点就是在它可以将一群相关的产品集合起来。
对比一下,使用场景也就清楚了:当需要创建产品家族和想让制造的相关产品集合起来时,使用抽象工厂模式;当仅仅想把客户代码从需要实例化的具体类中解耦,或者如果目前还不明确将来需要实例化哪些具体类时,可以使用工厂方法模式。
有些时候 创建型模式 是可以重叠使用的,有一些 抽象工厂模式 和 原型模式 都可以使用的场景,这个时候使用任一设计模式都是合理的;在其他情况下,他们各自作为彼此的补充: 抽象工厂模式 可能会使用一些原型类来克隆并且返回产品对象。
抽象工厂模式 , 建造者模式 和 原型模式 都能使用 单例模式 来实现他们自己; 抽象工厂模式 经常也是通过 工厂方法模式 实现的,但是他们都能够使用 原型模式 来实现;
通常情况下,设计模式刚开始会使用 工厂方法模式 (结构清晰,更容易定制化,子类的数量爆炸),如果设计者发现需要更多的灵活性时,就会慢慢地发展为 抽象工厂模式 , 原型模式 或者 建造者模式 (结构更加复杂,使用灵活);
原型模式 并不一定需要继承,但是它确实需要一个初始化的操作, 工厂方法模式 一定需要继承,但是不一定需要初始化操作;
使用 装饰者模式 或者 组合模式 的情况通常也可以使用 原型模式 来获得益处;
单例模式 中,只要将构造方法的访问权限设置为 private 型,就可以实现单例。但是 原型模式 的 clone 方法直接无视构造方法的权限来生成新的对象,所以, 单例模式 与 原型模式 是冲突的,在使用时要特别注意。
https://github.com/zhaozepeng/Design-Patterns/tree/master/AbstactFactoryPattern