On the IOS design patterns Abstract Factory (Abstract Factory)

Outline

  In the previous two chapters, introduced the simple factory pattern and factory method pattern , we know that a simple factory pattern advantage is removed dependent on the client and the specific products, the disadvantage is a violation of the " open - Principles close "; the factory method pattern to overcome a simple factory pattern defects, will create work products into the concrete factory class, each class is responsible for generating a factory product. However, in practice, the only case of a factory class to create a single product rarely, usually a factory class will be responsible for creating a series of related products, if we are to design such a system, the factory method pattern obviously can not meet the needs of the application of this chapter to introduce the abstract factory pattern, you can solve the problem of a range of products created.

definition

  "Create a series of related or dependent objects interface, without specifying their concrete classes."

  • Original definition appeared in "Design Patterns" (Addison-Wesley, 1994) .

Structure chart

 

  First of several roles structure diagram above will be described below:

  • AbstractFactory : abstract factory interface, which should include an abstract method for all products created;
  • ConcreteFactory1 and ConcreteFactory2 : concrete factory, create a product target specific implementation;
  • AbstractProductA and AbstractProductB : abstract product, they may have a variety of different implementations;
  • ProductA1ProductA2ProductB1ProductB2:具体的产品,是抽象产品的具体实现。

  从结构图中可以看到,抽象工厂方法最大的好处是能够很方便的变换产品系列(例如id<AbstractFactory> factory =[ [ConcreteFactory1 alloc] init],只需要将ConcreteFactory1换成ConcreteFactory2,就可以创建ProductA2ProductB2)。另外,抽象工厂方法让具体的创建实例过程与客户端分离,客户端是通过它们的抽象接口操作实例,产品的具体类名也被具体工厂的实现分离,不会出现在客户代码中(例如id<AbstractProductA> product = [factory createProductA],客户端根本不知道具体的类名是ProductA1还是ProductA2)

  但是,抽象工厂方法也是存在缺点的,比如说现在我们要增加一个新的产品,首先,我们需要增加三个类:AbstractProductCProductC1ProductC2;另外,我们还需要更改三个类:AbstractFactoryConcreteFactory1ConcreteFactory2,这样,很明显是违背“开放-关闭原则”。这也是可以理解的,没有任何一个设计模式是完美没有瑕疵的,这就好比世界上没有打不败的武功一样。我们可以做的就是在实际的需求中,尽可能的将变化点进行隔离,以达到变化发生的时候,对整个系统的影响最小,变化所带来的变更和成本最低。

示例

  还是继续简单工厂模式工厂方法模式的应用场景,这里将场景稍微改变一下:我们知道,绘制统计图形的方案有多种,我们既可以使用OWC来绘制统计图形,也可以使用HTML 5来绘制统计图形,或者其他的一些第三方插件来进行绘图,等等。这里我们用OWCHTML 5绘制统计图形来说明抽象工厂模式(注意:示例和场景只是为了说明设计模式的思想,并不是说实际开发中我们就会这么使用)。先来看看新应用场景使用抽象工厂模式实现的结构图:

 

  根据结构图,我们来看看部分源码(完整代码在后面会提供下载)

  AbstractLine.h

1 @protocol AbstractLine <NSObject>
2 
3 - (void)drawLine;

  AbstractPie.h

1 @protocol AbstractPie <NSObject>
2 
3 - (void)drawPie;

  AbstractFactory.h

1 @protocol AbstractFactory <NSObject>
2 
3 - (id<AbstractLine>)createLine;
4 - (id<AbstractPie>)createPie;

  客户端调用代码:

1         id<AbstractFactory> factory = [[[HTML5Factoryalloc] init] autorelease];
2 //        id<AbstractFactory> factory = [[[OWCFactory alloc] init] autorelease];
3         id<AbstractLine> line = [factory createLine];
4         id<AbstractPie> pie = [factory createPie];
5 
6         [line drawLine];
7         [pie drawPie];

  从调用代码我们可以看到抽象工厂的两个优点:

  • 能够很方便的变换产品系列;
  • 具体的创建实例过程与客户端分离,客户端是通过它们的抽象接口操作实例,产品的具体类名也被具体工厂的实现分离,不会出现在客户代码中。

  抽象工厂模式的缺点我们前面也分析了:在新加产品的需求下,违背开放-封闭原则。通过优缺点的比较,我们可以在如下场景下使用抽象工厂模式:功能模块已经非常成熟,基本上不需要太多修改,但是有可能会替换掉实现这些功能模块的类的那种情况。比如说数据库链接,所有的JDBC功能模块几乎一样,只不过种类有所不同,有些是SQL-Server,有些是Oracle,那么这时候用抽象工厂来实现,面对更换数据库的情况,就比较方便了。

  【小思考】:从上面的客户端调用代码看到,如果有多处变换产品系列的地方,我们需要每处都进行修改,这样的话,实际上也没有达到我们的效果:应对变化,尽可能少的修改代码。那么该怎样处理这种情况呢?解决方案可以参看工厂方法模式中的思考小节。

 

  源码下载

抽象工厂模式&建造者模式

  抽象工厂模式和建造者模式都属于创建型模式,它们在对象创建方面存在许多相似之处。但是,两者也存在较大的区别,具体如下:

建造者模式

抽象工厂模式

构建复杂对象

构建简单或复杂对象

以多个步骤构建对象

以单一步骤构建对象

以多种方式构建对象

以单一方式构建对象

在构建过程的最后一步返回产品

立刻返回产品

专注一个特定产品

强调一套产品

抽象工厂模式&工厂方法模式

  工厂方法模式只有一个抽象产品类,而抽象工厂模式有多个;工厂方法模式中工厂类一般只有一个方法,创建一种产品;抽象工厂模式中工厂类一般有多个方法,创建一系列产品。

  可以这么来理解:工厂方法模式是一种极端情况的抽象工厂模式,而抽象工厂模式可以看成是工厂方法模式的一种推广。

  返回目录

转载于:https://www.cnblogs.com/eagle927183/p/3479644.html

Guess you like

Origin blog.csdn.net/weixin_34384915/article/details/93725179