ABSTRACT FACTORY抽象工厂 - 对象创建型模式（四）

最新推荐文章于 2024-09-11 00:42:35 发布

qq_28809143

最新推荐文章于 2024-09-11 00:42:35 发布

阅读量304

点赞数

分类专栏：设计模式

本文链接：https://blog.csdn.net/qq_28809143/article/details/51301901

版权

设计模式专栏收录该内容

4 篇文章 0 订阅

订阅专栏

1,.意图
提供一个创建一系列相关或相互依赖对象的接口，而无需指定他们具体的类。
2.别名
Kit
3.动机
考虑一个支持多种视感标准的用户界面工具包，列入Motif和Presentation Manager.不同的视感风格为诸如滚动条、窗口和按钮等用户界面“窗口组件”定义不同的外观和行为。为保证视感风格标准件的可遗植性，一个应用不应该为一个特定的视感外观硬编码它的窗口组件。在整个应用中实例化特视感风格的窗口组件类将使得以后很难改变视感风格。
为解决这一问题我们可以定义一个抽象的WidgetFactory类，这个类声明了一个用来创建每一个类基本窗口组件的接口。每一类窗口组件都有一个抽象类，而具体子类则实现了窗口组件的特定视感风格。对于一个抽象窗口组件类，WidgetFactory接口都有一个返回新窗口组件对象的操作。客户调用这些操作一获得窗口组件实例。但客户并不知道他们正在使用的是那些具体类。这样客户就不依赖与一般的视感风格，
这里写图片描述
每一种视感标准都对应于一个具体的WidgetFactory子类。每一个子类实现那些用于创建合适视感风格窗口组件的操作。列如，MotifWidgetFactory的CreateScrollBar操作实例化并返回一个Motif滚动条，而相应的PMWidgetFactory操作返回一个PresentationManager的滚动条。客户仅通过WidgetFactory接口创建串口组件，他们并不知道哪些类实现特定视感风格的·窗口组件。换言之，客户仅与抽像类定义的接口交互，而不使用特定的具体类的接口。
WidgetFactory也增强了具体窗口组件类之间依赖关系。一个Motif的滚动条应该与Motif按钮，Motif正文编辑器一起使用，这一约束条件作为使用MotifWidgetFactory的结果被自动加上。
4.适用性
在以下情况可以使用Abstract Factory模式

* 一个系统要独立于它的产品的创建，组合和表示时。
* 一个系统要由多个产品系列中的一个来配置时。
* 当你强调一系列相关的产品对象的设计一遍进行联合使用时。
* 当你提供一个产品类库，而指向显示他们的接口而不是实现时。

5.结构
此模式的结构如下图所示
这里写图片描述
6.参与者
AbstractFactory(WidgetFactory)
一个声明一个创建抽象产品对象的操作接口。
ConcreteFactory(MotifWidgetFactory,PMWidgetFactory)
实现创建具体产品对象的操作。
AbstractProduct(Windows,ScrollBar)
-为一类产品对象声明一个接口。
ConcreteProduct(MotifWindow,MotifScrollBar)
定义一个将被相应的具体工厂创建的产品对象。
实现AbstractProduct接口。
Client
仅使用由AbstractFactory和AbstractProduct类声明的接口。
7，协作
通常在运行时刻创建一个ConcreteFactory类的例。这一具体的工厂创建具有特定实现的产品对象。为穿件不同的产品对象，客户应使用不同的具体的工厂。
AbstractFactory将产品对象的创建延迟到他的ConcreteFactory子类。
8 效果
AstractFactory模式有下面的一些优点和缺点
1) 他分离了具体的类 Abstract Factory模式帮助你控制一个应用创建的对象的类。因为一个工厂封装创建产品对象的责任和过程，它将客户鱼类的实现分离。客户通过他们的抽象接口操纵实例。产品的类名也在具体工厂的实现被分离；他们不出现在客户代码中。
2) 它使得易于交换产品系列一个具体工厂类在一个应用中仅出现一次—即在他初始化的时候。这是得改变一个应用的具体工厂变得很容易。他只需要改变具体的工厂即可使用不同的产品配置，这是因为一个抽象工厂创建了一个完整的产品系列，所以整个产品系列会立刻改变。在我们的用户界面的列子中，我们仅需要转换到响应的工厂对象并重新创建接口，就可实现从Motif窗口组件转换为Presentation Manager窗口组件。
3）它有利于产品的一致性当一个系列中的产品对象被设计成一起工作时，一个应用一次只能使同一个系列中的对象，这一点很重要。而AbstractFactory很容易实现这一点。
4）难以支持新种类的产品难以扩展抽象工厂以生产新种类的产品。这是因为AbstractFactory接口却低昂了可以被创建的产品集合。支持新种类的产品就需要扩展该工厂接口，这将涉及AbstractFactory类及其所有子类的改变。

AbstractFactory
public interface IAnimalFactory {

ICat createCat();

IDog createDog();

}

ConcreteFactory
public class BlackAnimalFactory implements IAnimalFactory {

public ICat createCat() {
    return new BlackCat();
}

public IDog createDog() {
    return new BlackDog();
}

}

public class WhiteAnimalFactory implements IAnimalFactory {

public ICat createCat() {
    return new WhiteCat();
}

public IDog createDog() {
    return new WhiteDog();
}

}

AbstractProduct
public interface ICat {

void eat();

}

public interface IDog {

void eat();

}

ConcreteProduct
public class BlackCat implements ICat {

public void eat() {
    System.out.println("The black cat is eating!");
}

}

public class WhiteCat implements ICat {

public void eat() {
    System.out.println("The white cat is eating!");
}

}

public class BlackDog implements IDog {

public void eat() {
    System.out.println("The black dog is eating");
}

}

public class WhiteDog implements IDog {

public void eat() {
    System.out.println("The white dog is eating!");
}

}

Client
public static void main(String[] args) {
IAnimalFactory blackAnimalFactory = new BlackAnimalFactory();
ICat blackCat = blackAnimalFactory.createCat();
blackCat.eat();
IDog blackDog = blackAnimalFactory.createDog();
blackDog.eat();

IAnimalFactory whiteAnimalFactory = new WhiteAnimalFactory();
ICat whiteCat = whiteAnimalFactory.createCat();
whiteCat.eat();
IDog whiteDog = whiteAnimalFactory.createDog();
whiteDog.eat();

}

result
The black cat is eating!
The black dog is eating!
The white cat is eating!
The white dog is eating!