工厂模式的简单例子
2016-02-26 14:17
218 查看
当A对象需要调用B对象的方法是,许多初学者会选择使用new关键字来创建一个B实例,然后调用B实例的方法。从语法角度来看,这种做法没有任何问题,这种做法的坏处在于:A类的方法实现直接调用了B类的类名(这种方式也被称为硬编码耦合),一旦系统需要重构;需要使用C类来代替B类时,程序不得不写A类代码。如果应用中有100个或10000个类以硬编码耦合了B类,则需要重新改写100个,10000个地方….
换一个角度来看这个问题:对于A对象而言,它只需要调用B对象的方法,并不关心B对象的实现、创建过程。考虑让B类实现一个IB接口,而A类只需要IB接口耦合——A类并不直接使用new关键字来创建B实例,而是重新定义一个工厂类:IBFactory,由该工厂类来负责创建IB实例;而A类通过IBFactory工厂的方法得到IB的实例。
通过该用上面设计,则A类需要与IBFactory耦合,和需要与IB接口耦合,如果系统需要重构:需要使用C类代替B类,则只需要让C类实现IB接口,并改写IBFactory工厂中创建IB实例的实现代码,并让该工厂产生C(实现IB接口)实例即可、由于所以来IB实例的对象都是通过工厂来获取IB实例的,所以他们都将改为获得C类实例,这就完成了系统重构。
out接口(相当抽象产品):
Printer实现out接口(相当具体产品):
工厂类(相当简单工厂),返回实现了Output接口的Printer的实例:
如果系统需要重构,则只需要让替换类实现Output接口,并改下OutputFactory类的getOutput方法即可。
优点
工厂类是整个模式的关键。包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象。通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。明确了各自的职责和权利,有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑,违反了高内聚责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。
当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;
这些缺点在工厂方法模式中得到了一定的克服。
使用场景
工厂类负责创建的对象比较少;
客户只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心;
由于简单工厂很容易违反高内聚责任分配原则,因此一般只在很简单的情况下应用。
换一个角度来看这个问题:对于A对象而言,它只需要调用B对象的方法,并不关心B对象的实现、创建过程。考虑让B类实现一个IB接口,而A类只需要IB接口耦合——A类并不直接使用new关键字来创建B实例,而是重新定义一个工厂类:IBFactory,由该工厂类来负责创建IB实例;而A类通过IBFactory工厂的方法得到IB的实例。
通过该用上面设计,则A类需要与IBFactory耦合,和需要与IB接口耦合,如果系统需要重构:需要使用C类代替B类,则只需要让C类实现IB接口,并改写IBFactory工厂中创建IB实例的实现代码,并让该工厂产生C(实现IB接口)实例即可、由于所以来IB实例的对象都是通过工厂来获取IB实例的,所以他们都将改为获得C类实例,这就完成了系统重构。
out接口(相当抽象产品):
package com.fsti.factory.simplefactory; public interface Output { public final static Integer MAX_CACHE_LINE = 3; void getData(String str); void out(); }
Printer实现out接口(相当具体产品):
public class Printer implements Output { private String[] printData = new String[MAX_CACHE_LINE]; // 用以记录当前需打印的作业数 private int dataNum = 0; public void getData(String str) { if (dataNum >= MAX_CACHE_LINE) { System.out.println("输出队列一满,添加失败"); } else { printData[dataNum++] = str; } } public void out() { while (dataNum > 0) { System.out.println("打印机打印:" + printData[0]); // 把作业整体前移一位,并将剩下的作业数减一 System.arraycopy(printData, 1, printData, 0, --dataNum); } } }
工厂类(相当简单工厂),返回实现了Output接口的Printer的实例:
public class OutputFactory { public Output getOutput() { return new Printer(); } }
// Computer类对接口Output形成依赖,将Computer与Printer实现类分离开来 public class Computer { private Output out; public Computer(Output out) { this.out = out; } public void keyIn(String str) { out.getData(str); } public void print() { out.out(); } public static void main(String[] args) { OutputFactory of = new OutputFactory(); Computer c = new Computer(of.getOutput()); c.keyIn("工厂模式之"); c.keyIn("简单工厂模式"); c.print(); } }
如果系统需要重构,则只需要让替换类实现Output接口,并改下OutputFactory类的getOutput方法即可。
优点
工厂类是整个模式的关键。包含了必要的逻辑判断,根据外界给定的信息,决定究竟应该创建哪个具体类的对象。通过使用工厂类,外界可以从直接创建具体产品对象的尴尬局面摆脱出来,仅仅需要负责“消费”对象就可以了。而不必管这些对象究竟如何创建及如何组织的。明确了各自的职责和权利,有利于整个软件体系结构的优化。
缺点
由于工厂类集中了所有实例的创建逻辑,违反了高内聚责任分配原则,将全部创建逻辑集中到了一个工厂类中;它所能创建的类只能是事先考虑到的,如果需要添加新的类,则就需要改变工厂类了。
当系统中的具体产品类不断增多时候,可能会出现要求工厂类根据不同条件创建不同实例的需求.这种对条件的判断和对具体产品类型的判断交错在一起,很难避免模块功能的蔓延,对系统的维护和扩展非常不利;
这些缺点在工厂方法模式中得到了一定的克服。
使用场景
工厂类负责创建的对象比较少;
客户只知道传入工厂类的参数,对于如何创建对象(逻辑)不关心;
由于简单工厂很容易违反高内聚责任分配原则,因此一般只在很简单的情况下应用。
相关文章推荐
- nginx开发(一) 源码-编译
- iOS开发拓展篇-XMPP简单介绍
- WebKit之V8引擎(js调度C++)
- PAT (Basic Level)1021. 个位数统计
- UVA 10285(p304)----Longest Run on a Snowboard
- 高效Java编程工具集锦
- 【转】Web实时通信之Socket.IO ,真正的兼容ie
- 利用Scala语言开发Spark应用程序
- android中Intent和IntentFilter的区别
- 简单分页类
- 将某一类型文件还原为无默认打开方式
- Java容器学习之——List
- corosync+drbd+mysql实现的高可用
- zabbix 安装使用笔记
- Pony ORM
- 记一次不错的电话面试
- 第3章 Android Dalvik虚拟机 第三节(上)
- 八、UiScrollable API 详细介绍
- Leet Code OJ 226. Invert Binary Tree [Difficulty: Easy]
- 嵌入式开发板iTOP4412学习开发板