设计模式学习之Abstract Factory模式

学习的进度最近又慢了, 各种各样的事, 然后总是容易把这个那个都弄不好。 实习还是没有着落, 实力还需加强, 努力吧, keep going.

抽象工厂模式。

工厂模式一共有5个:1.抽象工厂(Abstract Factory);2.工厂方法(Factory Method);3.建造模式(Builder);4.单例模式(Singleton);5.原型模式(Prototype)。

这5个都属于创建型模式, 而前面学习的Bridge模式、Adapter模式、Facade模式都属于结构型模式,Strategy模式则属于行为型模式。

先来看看抽象工厂的定义吧:为创建一组相关或相互依赖的对象提供一个接口, 而且无需指定它们的具体类。

面向对象的设计方法学最重要的一个概念之一就是封装变化, 将问题放到变化上来而不是放到具体的实现当中。 具体的实现是可变的, 但是这些变化是可封装的, 是共性的, 从概念视角和规约视角去分析问题。 我们要达到的目的是使各个类、或者说各个对象是高度内聚和低耦合的。

从定义分析, Client类和Product类是属于相关的,但是假如Product类有很多, 但是他们的功能大致类似,仅仅是实现方式或者实现表象不同, 如果client需要制定它们的具体类的话, client类和product类的耦合就会变大, 假如product类增加了一个新类, 就必须为client增加一个新的接口。

举个例子吧, 老样子。妹纸什么的最有爱了。 我约了MM一起去一个新开的餐厅吃饭, 听说气氛很不错, 和MM幽会吃饭肯定是必不可少的。 但是这个是新开的餐厅, 也不知道都有些什么菜。于是我把服务员叫来, 问他:冷菜有什么推荐菜么?小炒有什么推荐菜?汤类又有什么特色的呢? 服务员bulabula的说了一通,然后我和MM也是第一次来,就听服务员的推荐啦。 于是点菜功夫就完成了(ps:泡MM可别像我这么干, 你要知道,就算你不知道有什么菜, 你也得拿着菜单装模做样看一通,然后怎么点就你自己决定了, 比如什么名字听起来好听的 -。- 不然MM可能觉得你没主见神马的~然后说不定你就泪奔了)。当然,从生活的角度来说,这种纯粹由服务员推荐的例子不会太少,但是也不太多, 也有人认为服务员推荐的可能就是贵的, 味道不一定咋地, 很多人还是习惯自己看菜单点, 甚至有人都把菜单给背下来了。 生活么, 这样的做法太正常了, 但是从设计模式去分析的话,服务员提供的是一个接口, 使用接口的前提是你不关心他的内在实现, 并相信这个接口是工作正常、是可信任的。也就是说这些是有点理想化、可控制的, 而生活么, 很多事情是你无法掌控的, 比如地沟油神马的·~~

扯得有点远了,哈哈,跑题神马的。

上个图吧。

抽象工厂模式提供了一个新的分解方式——根据职责分解。 使用这种方法将问题分解为:

1:谁在使用特定对象(ApControl)(本例中的点菜的我);

2:谁来决定使用那些特定对象(AbstractFactory)(当然是推荐菜品的服务员啦);

当问题域中存在不同组的对象, 而且每组都用于不同情况时, 就应该使用AbstractFactory模式。可以根据各种理由定义对象的组。比如:

1:不同的操作系统(编写跨平台应用程序时);

2:不同的性能准则;

3:应用程序的不同版本;

4:应用程序的不同特点;

5:与地域有关的资源的不统计和(比如方言、日期格式);

本例子中不同的组就是凉菜、热菜甜品这些不同形式的菜啦~~~~

使用这种方式的优点就是, 我不用再去记那些菜名和菜的种类, 而且当店里有新的菜式出现时我也可以通过服务员知道。

Abstract Factory模式的关键特征:

意图:需要为特定的用户(或情况)提供对象组。

问题:需要实例化一组相关的对象。

解决方案:协调对象组的创建。提供一种方式, 将如何执行对象实例化的规则从使用这些对象的客户对象提取出来。

参与者与写作者:AbstractFactory为如何创建对象组的每个成员定义接口。一般每个组都有独立的ConcreteFactory进行创建。

效果:这个模式将“使用哪些对象”的规则与“如何使用这些对象”的逻辑分离开来。

实现:定义一个抽象类来指定创建哪些对象。 然后为每个组实现一个具体类。 可以用表或文件来完成同样的任务。

AbstractFactory模式的通用结构图:

[caption id=”attachment_574” align=”aligncenter” width=”596”]abstract-factory abstract-factory[/caption]

路漫漫啊~加油~

参考:《设计模式解析》

blog comments powered by Disqus