机房收费系统之工厂

抽象工厂（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图来自《大话设计模式》