灵活地应用抽象工厂方法模式

       我们在实际项目开发过程中应该说用得较多的还是抽象工厂方法模式（例如：在开发出来的一个网站可能连接不同的数据，我们需要用抽象工厂的方式把实例化具体对象（SqlServerUser对象）工厂中去）。废话少说，我们先来看看定义：提供一个创建一系列相关或者相互依赖对象的接口，而不需要制定他们具体的类。

       什么意思呢？有这个定义有点拗口，咱们解释一下：1.首先我们定义一个工厂的接口（IFactory），并在这个接口中去声明返回接口操作的方法；2.在继承这个接口工厂（SqlServerFactory）并定义对应的接口操作方法；3.在客户端代码就简单了：IFactory factory=new SqlServerFactory（）； IUser user= factory.CreateUser();

     

     为什么我们项目开发的时候这个设计模式呢？我们在进行数据库装换的时候，每个数据库的操作有可能不同（例如：Oracle 、SqlServer 数据库），所以我们在实际项目中需要动态的去选择我们要创建那个操作对象；引入此模式后，我们客户端的代码无需关系具体创建的操作对象，而只需引用返回的对象就行；当然此设计模式也有弊端；我们在增加一个Department部门表的操作时候，需要创建对应的类：IDepartment，SqlserverDepartment，AccessDepartment类；额外地增加了很多的代码；但是这个代码是值得的；我们在后续维护系统的时候减少很多的工作量。

      大家可能已经发现问题了：1.在增加Department部门时候，同时需要修改IFactory，SqlServerFactory，AccessFactory；2.我们在客户端调用使用的时候直接需定义一个具体的工厂实例（IFactory Factory=new SqlServer）,如果说客户端有上千次，我需要替换上千次；我们把代码进行修改综合前面我们将的简单工厂+抽象工厂的方式编码：

      这样做得话，省去了具体的工厂、抽象工厂编写（这句话有点不严谨，DataAccess类类似于简单工厂的工厂类）；客户端代码在进行编码的时候，就直接DataAccess.CreateUser() 方法返回User的操作类（注意：把CreateUser（）方法定义为static 类型的）；就算客户端需要更改数据库，那也不怕了。

      这种方式不是最好的解决实际项目的方式，只能打90分。为什么？大家会注意到在DataAccess.CreateUser()

方法中我们要根据db变量判断我们需要创建怎么样的操作User类。我们可以用反射技术彻底解决这个问题（代码：Assemly.Load("程序集名称").createInstance("命名空间.类的名称")）；有给大家下去思考，相信你会有满意的答案。最后，提示大家在加入反射的时候需要引用包（using System.Reflection;）