设计模式:工厂在收费系统中的应用
2011-05-04 23:01
330 查看
抽象工厂(Abstract Factory):提供一个创建一系列相关或相互依赖对象的结构,而无需指定他们具体的类。
抽象工厂UML图:
AbstractProductA和AbstractProductB是两个抽象产品,它们可能是两种不同的实现。在机房收费系统中可以理解为对两个表的不同操作。
而ProductA1和ProductB1可以理解为sql的操作,ProductA2和ProductB可以理解为access的操作。因为ProductA1和ProductB1是依赖ConcreateFactory1,所以ConcreteFactory1可以理解为sqlFactory,同理右边ConcreteFactory1(应该为ConcreteFactory2)可以理解为AccessFactory。
通常是在运行时刻在创建一个ConcreteFactory类的实例,这个工厂在创建特定的产品对象,为创建不同的产品对象,客户端应使用不同的具体工厂。
在机房收费系统中:
通过工厂创建了借口,去实现接口。就相当于上图中的ConcreteFactory1去创建了ProductA1和ProductB1。这里我没有抽象,只是用了抽象工厂的一部分功能,这里的dalFactory是sqldalFactory,如果存在将来把数据库换成oracle,就可以抽象出一个抽象的工厂,就是上图中的AbstractFactory。在有不同的实现,从而实现出oracleFactory,dalInterface中的一些抽象和实现和工厂是同理的。
这样做的好处就是易于交换产品系列,是变化数据库变得更简单。
看到了抽象工厂,又重新看了一遍工厂模式还有简单工厂模式。
简单工厂:
这个简单工厂很简单了,只是利用简单工厂中的select case根据不同的条件去创造不同的类。如果添加其他操作,必须修改工厂,这个违反了开放封闭原则。而工厂模式很好的克服了这一困难。
工厂模式:
UML图
在工厂模式中,把原来的简单工厂变成了抽象工厂。如果添加一个新的功能,只需在抽象工厂的下面添加一个子类,去继承抽象工厂,从而解决了简单工厂中的添加功能问题。这里只需添加,而不用去修改原来的工厂。
简单工厂的好处是自动判断了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类。
而抽象工厂比工厂模式只是在具体实现的时候又多了一个抽象,可能这样说不是很专业。可以理解为具体工厂在实例化一些类时,被实例化的这些类之间有一些相关的联系,从而在实例化的类之间在抽象出抽象类。
工厂这个东西看似简单,但是往往简单的东西包含着大道理。千万别小觑它。
PS:部分UML图来自《大话设计模式》
抽象工厂UML图:
AbstractProductA和AbstractProductB是两个抽象产品,它们可能是两种不同的实现。在机房收费系统中可以理解为对两个表的不同操作。
而ProductA1和ProductB1可以理解为sql的操作,ProductA2和ProductB可以理解为access的操作。因为ProductA1和ProductB1是依赖ConcreateFactory1,所以ConcreteFactory1可以理解为sqlFactory,同理右边ConcreteFactory1(应该为ConcreteFactory2)可以理解为AccessFactory。
通常是在运行时刻在创建一个ConcreteFactory类的实例,这个工厂在创建特定的产品对象,为创建不同的产品对象,客户端应使用不同的具体工厂。
在机房收费系统中:
通过工厂创建了借口,去实现接口。就相当于上图中的ConcreteFactory1去创建了ProductA1和ProductB1。这里我没有抽象,只是用了抽象工厂的一部分功能,这里的dalFactory是sqldalFactory,如果存在将来把数据库换成oracle,就可以抽象出一个抽象的工厂,就是上图中的AbstractFactory。在有不同的实现,从而实现出oracleFactory,dalInterface中的一些抽象和实现和工厂是同理的。
这样做的好处就是易于交换产品系列,是变化数据库变得更简单。
看到了抽象工厂,又重新看了一遍工厂模式还有简单工厂模式。
简单工厂:
这个简单工厂很简单了,只是利用简单工厂中的select case根据不同的条件去创造不同的类。如果添加其他操作,必须修改工厂,这个违反了开放封闭原则。而工厂模式很好的克服了这一困难。
工厂模式:
UML图
在工厂模式中,把原来的简单工厂变成了抽象工厂。如果添加一个新的功能,只需在抽象工厂的下面添加一个子类,去继承抽象工厂,从而解决了简单工厂中的添加功能问题。这里只需添加,而不用去修改原来的工厂。
简单工厂的好处是自动判断了必要的逻辑判断,根据客户端的选择条件动态实例化相关的类。
而抽象工厂比工厂模式只是在具体实现的时候又多了一个抽象,可能这样说不是很专业。可以理解为具体工厂在实例化一些类时,被实例化的这些类之间有一些相关的联系,从而在实例化的类之间在抽象出抽象类。
工厂这个东西看似简单,但是往往简单的东西包含着大道理。千万别小觑它。
PS:部分UML图来自《大话设计模式》
相关文章推荐
- 工厂设计模式的探讨——iOS类簇的应用分析
- 代理模式(二):代理模式应用实例(收费商务信息查询系统)
- Retrofit框架设计-构建者+工厂模式高级应用
- 系统架构技能之设计模式-工厂模式
- 设计模式之工厂模式——应用最广泛的模式
- 设计模式应用与发展之工厂模式 c++篇
- 设计模式在一个系统架构设计中的应用
- [WEB系统中的设计模式(暂时放在这里,看不大懂)]mvc在web系统中的模式与应用
- Nutz 设计模式应用 --- 工厂方法
- 简单工厂设计模式实现商店买牙膏收费案例过渡到结合策略模式的理由全解
- 设计模式在软件应用系统开发中的实战参考
- 设计模式——抽象工厂模式及在jdk中的应用+几种工厂模式的比较
- 设计模式之策略模式在地铁票价系统中的应用
- Retrofit框架设计-构建者+工厂模式高级应用
- 设计模式的应用-工厂方法实现3层模型解耦
- 设计模式在游戏中的应用--工厂方法(五)
- 系统架构技能之设计模式-工厂模式
- 设计模式在交易系统中的应用
- 设计模式中简单工厂模式的应用----java
- Nutz 设计模式应用 --- 静态工厂方法