旧瓶装新酒的抽象工厂

自上而下的使用设计模式与自上而下的揭示迭代式开发和持续性重构结合起来。所以我们尽可能的去寻找使用模式改进代码的新可能。记录了具有公认良好属性的程序结构。然而，并非每一个设计模式都能完美的适用并应用于我们的项目。所以如果我们从最初的代码去了解每一个设计模式的针对具体情况不断演变而生的过程。获取我们能重新得到一种思路和一种共鸣，从而简化我们的项目。

现在我们有两个这样的类。SQLServerUser 调用BasicInfo 的信息。

后来又来了一个AccessUser 也要调用BasicInfo信息，而且它的方法跟SQLServer一样。

既然两个类中的方法都相同。不得不想，以后还有没有可能有其他的类增加，导致继续重复。没错，在我们的需求里，以后还有可能换成OracleUser等。这就往往意味着又有了坏的味道。重复可以进行抽象。
抽象的方法有很多种。使用接口，抽象类，或是虚类。普通/抽象类+虚方法等。

那么他们的区别：

从抽象的内容来看
1. 接口只定义方法名，参数和返回值。所以它更像一种规范。
2. 抽象类中可以有字段，可以存在普通方法（可以有方法体）。也存在抽象方法，只是抽象方法同样不能有方法体。
3. 虚方法必须有方法体。子类可以重写。
从继承的情况来看
1. 一个子类只能继承一个抽象类，而一个子类能继承多个不同的接口。
2. 子类需要全部重写父类的接口，也需要全部重写父类的抽象类，却不需要全部重写父类的虚方法。

分析：
1. 由于多个数据库，有多个相同的方法，却没有多个相同实现（所以不是一定要用抽象类）。
2. 又由于子类只能继承一个抽象类，能继承多个接口。

综上：采用接口最佳。

于是有了下图。

这样我们的代码有了一定的改观。以后再扩展直接去实例化IDataBase 这个接口。再调用形式上也从
以前的 SQLServerUser squServerUser=new SQLServerUser();
改成了 IDataBase dataBase=new SQLServerUser();

其实这还是半解耦状态。暂且放一放。
需求：因为数据库还有多张表，必然还会有对应的多个类似的形式。

如此，我们就需要不断的去实例化。
IDataBase dataBase=new SQLServerUser();
Idepartment department=new SQLServerDepartment();

哪一天一旦说更改了Access数据库。我们就需要将遍布到程序所有蒋璐的所有这些实例化的地方全部改为Access相关类。
不如我们用一个统一的类把创建类管理起来。

这样我们只需要实例化一个SQLFactory 就有了SQL的一套类。这就是抽象工厂最初的模式了。然而我们来看左边的两个Factory 其方法都是一致的。这时候，我们还可以继续按照最初的思路对其进行抽象，接口抽象类等，当然我也可以按照我们的简单工厂，通过case语句将其合并为一个类。这样DataAccess类中可以写为这样。

  class DataAccess{private static readonly string db = "Sqlserver";//private static readonly string db = "Access";public static IUser CreateIDataBase(){IUser result = null;switch (db){case "Sqlserver":result = new SqlserverUser();break;case "Access":result = new AccessUser();break;}return result;}public static IDepartment CreateDepartment() { //............}}

还是那句话，没有最合适的设计模式，因为所有特定的设计模式都是为了应对特定的需求和变化。我们只能预测需求的变化方向来选择和调整合适的设计模式。Switch Case 就回到了最初的简单工厂模式。我们也知道当有新增加一个ORacle数据库时它是有不足的。因为它需要修改switch Case里面的内容。
这时候，我们又选择了反射机制+配置文件来让其自己“去某个地方找应该要实例化的类是哪一个”。

主要的是下面这几句话：

Private static readonly string db=ConfigurationManager.AppSettings["DB"];Public static Iuser CreateUser(){String className=AssemblyName+"."+db+"User";Return (IUser)Assembly.Load(AssemblyName).CreateInstance(className);
}

总结

以前侧重于抽象工厂能够帮助我们解决问题。而本篇博客侧重于在某一种需求出来之后它是怎么根据变化进行的调整。这往往能给做开发的我们提供一个更好的思路怎么去提高自己的代码逼格。当然，从中我们也感受到，优秀的设计并非一蹴而就，它们都经历的艰难-笨重-和反思。随着代码的不断改变，看到了更好的设计方案。

对于程序员来说，这种欣喜也许其它任何不可替代。

旧瓶装新酒的抽象工厂相关推荐

抽象工厂————三层架构
抽象工厂作用:降低BLL和Model层耦合度核心思想:1.通过接口类实现对象的分离 2.通过一个类,实现指定对象的创建,并且这个类通过配置文件决定获取哪个对象这样只要调用一个接口和这个类,就能 ...
抽象工厂模式 java实例 tclhaier_Unity常用的设计模式_工厂模式系列之抽象工厂模式...
在工厂方法模式中,工厂只负责生产具体的产品,每一个具体的工厂对应着一个具体的产品,工厂方法也具有唯一性,如果有时候我们需要一个工厂方法提供多个产品而不是一个单一的产品,例如:海尔品牌不止生产海尔TV, ...
设计模式：简单工厂、工厂方法、抽象工厂之小结与区别
简单工厂,工厂方法,抽象工厂都属于设计模式中的创建型模式.其主要功能都是帮助我们把对象的实例化部分抽取了出来,优化了系统的架构,并且增强了系统的扩展性. 本文是本人对这三种模式学习后的一个小结以及对他 ...
编程模式之美 -- 抽象工厂模式
文章目录 1. 解决问题 2. 应用场景 3. 实现如下: C++实现 C语言实现 4. 缺点 1. 解决问题在工厂方法模式中,我们卖衣服.此时我们为每一种衣服创建不同的工厂,帽子有一个工厂专门创建 ...
工厂方法模式和抽象工厂模式
工厂方法模式和抽象工厂模式工厂方法模式抽象工厂模式总结: 工厂方法模式 #include <string> #include <iostream>// Abstract ...
抽象工厂模式AbstractFactory
简介抽象工厂模式(Abstract Factory Pattern):提供一个创建一系列相关或相互依赖对象的接口,而无须指定它们具体的类.抽象工厂模式又称为Kit模式,属于对象创建型模式. 不同点 ...
工厂方法模式与抽象工厂模式的区别
工厂方法模式: 一个抽象产品类,可以派生出多个具体产品类. 一个抽象工厂类,可以派生出多个具体工厂类. 每个具体工厂类只能创建一个具体产品类的实例. 抽象工厂模式: 多个抽象产品类,每个抽象产品类可以 ...
设计模式C#描述——抽象工厂模式
设计模式C#描述--抽象工厂模式阅读此文应先阅读简单工厂模式与工厂方法模式抽象工厂模式是对象的创建模式,它是工厂方法模式的进一步推广. 假设一个子系统需要一些产品对象,而这些产品又属于一个以上的产 ...
设计模式之抽象工厂模式(Abstract Factory)摘录
面向对象系统的分析和设计实际上追求的就是两点:高内聚(Cohesion)和低耦合(Coupling). 23种GOF设计模式一般分为三大类:创建型模式.结构型模式.行为模式. 创建型模式包括:1.Fa ...

旧瓶装新酒的抽象工厂

旧瓶装新酒的抽象工厂相关推荐

最新文章

热门文章