《大话设计模式》之--第15章 就不能不换DB吗？----抽象工厂模式

第15章 就不能不换DB吗？----抽象工厂模式

15.1就不能不换DB吗？

“这么晚才回来，都11点了。”大鸟看着刚推门而入的小菜问道。
“我了个去~没办法呀，工作忙。”小菜叹气说道。
“怎么会这么忙。加班有点过头了呀。”
“都是换数据库惹的祸叹。”
“怎么了?”
“我本来写好了一个项目，是给一家企业做的电子商务网站，是用SQLServer作为数据库的，应该说上线后除了开始有些小问题，基本都还可以。而后，公司接到另外一家公司类似需求的项目，但这家公司想省钱，租用了一个空间，只能用Access，不能用SQL Server，于是就要求我今天改造原来那个项目的代码。”
“哈哈，你的麻烦来了。”
“是呀，那是相当的麻烦。但开始我觉得很简单呀，因为地球人都知道，SQL Server和Access在ADO.NET上的使用是不同的，在SQL Server上用的是System.Data.SqlClient命名空间下的SqlConnectian、SqlCommand、SqlParameter、 SqlDataReader、SqlDataAdapter，而Access则要用System.Data.OleDb命名空间下的相应对象，我以为只要做一个全体替换就可以了，哪知道，替换后，错误百出。”
“那是一定的，两者有不少不同的地方。你都找到了些什么问题?”
“实在是多呀。在插入数据时Access必须要insert into而SQL Server可以不用into的，SQL Server中的GeDate()在Access中没有，需要改成Now()，SQL Server中有字符串函数Substring，而Access中根本不能用，我找了很久才知道，可以用Mid，这好像是VB中的函数口”
“小菜还真犯了不少错呀，insert into这是标准语法，你干吗不加into，这是自找的麻烦。”
“这些问题也就罢了，最气人的是程序的登录代码，老是报错，我怎么也找不到出了什么问题，搞了几个小时口最后才知道，原来Access对一些关键字，例如password是不能作为数据库的字段的，如果密码的字段名是password，SQL Server中什么问题都没有，运行正常，在Access中就是报错，而且报得让人莫名其妙。”
“‘关键字’应该要用‘[’和‘]’包起来，不然当然是容易出错的。”
“就这样，今天加班到这时候才回来。”
“以后你还有的是班要加了。”
“为什么?”
“只要网站要维护，比如修改或增加一些功能，你就得改两个项目吧，至少在数据库中做改动。相应的程序代码都要改，甚至和数据库不相干的代码也要改，你既然有两个不同的版本，两倍的工作量也是必然的。”
“是呀，如果哪一天要用Oracle数据库，估计我要改动的地方更多了。”
“那是当然，Oracle的SQL语法与SQL Server的差别更大。你的改动将是空前的。”
“大鸟只会夸张，哪有这么严重，大不了再加两天班就什么都搞定了。”
“哼”，大鸟笑着摇了摇头，很不屑一顾，“菜鸟程序员碰到问颐，只会用时间来摆平，所以即使整天加班，老板也不想给菜鸟加工资，原因就在于此。”
“你什么意思嘛!”小菜气道，“我是菜鸟我怕谁。”接着又拉了拉大鸟，“那你说怎么搞定才是好呢?”
“知道求我啦，”大鸟端起架子，“教你可以，这一周的碗你洗。”
“行，”小菜很爽快地答应道，“在家洗碗也比加班熬夜强。”

15.2最基本的数据访问程序

“那你先写一段你原来的数据访问的做法给我看看。”
“那就用增加用户和得到用户为例吧。”

//用户类假设只有ID和Name两个字段，其余省略。
public class User
{
private int		id;
private String	name;

public int getId()
{
return id;
}

public void setId(int id)
{
this.id = id;
}

public String getName()
{
return name;
}

public void setName(String name)
{
this.name = name;
}
}
//SqlServerUser类，用于操作User表，假设只有新增用户和得到用户的方法，其余方法以及具体SQL语句省略。
public class SqlServerUser
{
public void insert(User user)
{
System.out.println("在SQL Server中给User表增加一条记录");
}

public User getUser(int id)
{
System.out.println("在SQL Server中根据ID得到User表一条记录");
return null;
}
}
//客户端代码
public class Main
{
public static void main(String[] args)
{
User user = new User();

SqlServerUser su = new SqlServerUser();

su.insert(user);

su.getUser(1);
}
}

“我最开始就是这样写的，非常简单。”

“这里之所以不能换数据库，原因就在于SqlServerUser su = new SqlServerUser()使得su这个对象被框死在了SQL Server上了。如果这里是灵活的，专业点的说法，是多态的，那么在执行su.insert(user)和su.getUser(1)时就不用考虑是在用SQL Server还是在用Access。”
“你的意思我明白，你是希望我用工厂方法模式来封装new SqlServerUser()所造成的变化？”
“小菜到了半夜，还是很清醒嘛，8错8错。工厂方法模式是定义一个用户创建对象的接口，让子类决定实例化哪个类，试试看吧。”
“中！”

15.3用了工厂方法模式的数据访问程序

小菜很快给出了工厂方法实现的代码。
代码结构图

//IUser接口，用于客户端访问，解除与具体数据库访问的耦合
public interface IUser
{
void insert(User user);

User getUser(int id);
}
//SqlServerUser类，用于访问SQL Server的User
public class SqlServerUser implements IUser
{
public void insert(User user)
{
System.out.println("在SQL Server中给User表增加一条记录");
}

public User getUser(int id)
{
System.out.println("在SQL Server中根据ID得到User表一条记录");
return null;
}
}
//AccessUser类，用于访问Access的User
public class AccessUser implements IUser
{
public void insert(User user)
{
System.out.println("在Access中给User表增加一条记录");
}

public User getUser(int id)
{
System.out.println("在Access中根据ID得到User表一条记录");
return null;
}
}
//IFactory接口，定义一个创建访问User表对象的抽象的工厂接口
public interface IFactory
{
IUser createUser();
}
//SqlServerFactory类，实现IFactory接口，实例化SqlServerUser
public class SqlServerFactory implements IFactory
{

public IUser createUser()
{
return new SqlServerUser();
}

}
//AccessFactory类，实现IFactory接口，实例化AccessUser
public class AccessFactory implements IFactory
{
public IUser createUser()
{
return new AccessUser();
}
}
//客户端代码
public class Main
{
public static void main(String[] args)
{
User user = new User();

IFactory factory = new SqlServerFactory();

IUser iu = factory.createUser();

iu.insert(user);
iu.getUser(1);
}
}

“大鸟，来看看这样写成不？”

“非常好。现在如果要换数据库，只需要把new SqlServerFactory()改成new AccessFactory()，此时由于多态的关系，使得声明IUser接口的对象iu事先根本不知道是在访问哪个数据库，却可以在运行时很好地完成工作，这就是所谓的业务逻辑与数据访问的解耦。”
“但是，大鸟，这样写，代码里还是有指明new SqlServerFactory()啊，我要改的地方，依然很多。”
“这个先不急，待会再说，问题还没有完全解决，你的数据库里面不可能只有一个User表吧，很可能有其他表，比如增加部门表（Department表），此时如何办呢？”
“啊，我觉得那要增加好多的类了，我来试试看。”
“多写些类有什么关系，只要能增加灵活性，以后就不用加班了。小菜好好加油。”

15.4用了抽象工厂模式的数据访问程序

小菜再次修改代码，拉回了关于部门表的处理。
代码结构图

//Department类
public class Department
{
private int		id;
private String	name;

public int getId()
{
return id;
}

public void setId(int id)
{
this.id = id;
}

public String getName()
{
return name;
}

public void setName(String name)
{
this.name = name;
}
}
//IDepartment接口，用于客户端访问，解除与具体数据库访问的耦合
public interface IDepartment
{
void insert(Department department);

Department getDepartment(int id);
}
//SqlServerDepartment类，用于访问SQL Server的Department
public class SqlServerDepartment implements IDepartment
{
public void insert(Department department)
{
System.out.println("在SQL Server中给Deaprtment表增加一条记录");
}

public Department getDepartment(int id)
{
System.out.println("在SQL Server中根据ID得到Deaprtment表一条记录");
return null;
}
}
//AccessDepartment类，用于访问Access的Department
public class AccessDepartment implements IDepartment
{
public void insert(Department department)
{
System.out.println("在Access中给Deaprtment表增加一条记录");
}

public Department getDepartment(int id)
{
System.out.println("在Access中根据ID得到Deaprtment表一条记录");
return null;
}
}
//IFactory接口，定义一个创建访问User表对象的抽象工厂接口
public interface IFactory
{
IUser createUser();

IDepartment createDepartment();
}
//SqlServerFactory类，实现IFactory接口，实例化SqlServerUser和SqlServerDepartment
public class SqlServerFactory implements IFactory
{
public IUser createUser()
{
return new SqlServerUser();
}

public IDepartment createDepartment()
{
return new SqlServerDepartment();
}
}
//AccessFactory类，实现IFactory接口，实例化AccessUser和AccessDepartment
public class AccessFactory implements IFactory
{
public IUser createUser()
{
return new AccessUser();
}

public IDepartment createDepartment()
{
return new AccessDepartment();
}
}
//客户端代码
public class Main
{
public static void main(String[] args)
{
User user = new User();
Department department = new Department();

// IFactory factory = new SqlServerFactory();

IFactory factory = new AccessFactory();

IUser iu = factory.createUser();

iu.insert(user);
iu.getUser(1);

IDepartment id = factory.createDepartment();

id.insert(department);
id.getDepartment(1);
}
}
结果显示：
在Access中给User表增加一条记录
在Access中根据ID得到User表一条记录
在Access中给Deaprtment表增加一条记录
在Access中根据ID得到Deaprtment表一条记录

“大鸟，这样就可以了，只需要改IFactory factory = new AccessFactory()为IFactory factory = new SqlServerFactory()，就可以实现了数据库访问的切换了。”
“很好嘛，实际上，在不知不觉间，你已经通过需求的不断演化，重构出了一个非常重要的设计模式。”
“这不就是刚才的工厂方法模式吗？”
“只有一个User类和User操作类的时候，是只需要工厂方法模式的，但现在显然你的数据库中有很多的表，而SQL Server与Access又是两大不同的分类，所以解决这种涉及到多个产品系列的问题，有一个专门的工厂模式叫抽象工厂模式。”

15.5抽象工厂模式

抽象工厂模式（Abstract Factory），提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类。
抽象工厂模式（Abstract Factory）结构图



“AbstractProductA和AbstractProductB是两个抽象产品，之所以为抽象，是因为它们都有可能有两种不同的实现，就刚才的例子来说就是User和Department，而ProductA1、ProductA2和ProductB1、ProductB2就是对两个抽象产品的具体分类的实现，比如ProductA1可以理解为是SqlServerUser，而ProductB1是AccessUser。”
“这么说，IFactory是一个抽象工厂接口，它里面应该包含所有的产品创建的抽象方法。而ConcreteFactory1和ConcreteFacotry2就是具体的工厂了。就像SqlServerFactory和AccessFactory一样。”
“理解的非常正确。通常是在运行时刻再创建一个ConcreteFactory类的实例，这个具体的工厂再创建具有特定实现的产品对象，也就是说，为创建不同的产品对象，客户端应该使用不同的具体工厂。”

15.6抽象工厂模式的优点和缺点

“这样做有虾米好处？”
“最大好处在于易于交换产品系列，由于具体工厂类，例如IFactory factory = new AccessFactory()，在一个应用中只需要在初始化的时候出现一次，这就使得改变一个应用的具体工厂变得非常容易，它只需要改变具体工厂即可使用不同的产品配置。我们的设计不能去防止需求的更改，那么我们的理想便是让改动变得最小，现在如果你要更改数据库访问，我们只需要更改具体的工厂就可以做到了。第二大好处在于，它让具体的创建实例过程与客户端分离，客户端是通过它们的抽象接口操纵实例，产品的具体类名也被具体工厂的实现分离，不会出现在客户端代码中。事实上，你刚才写的例子，客户端所认识的只有IUser和IDepartment，至于它是用SQL Server来实现还是用Access来实现就不知道了。”
“啊，我感觉这个模式把开放-封闭原则，依赖倒转原则发挥到极致了。”
“木啦木啦，木那么夸张的说，应该说就是这些设计原则的良好运用。抽象工厂模式也有缺点。你想的出来吗？”
“想不出来，我感觉它已经很好用了，哪有什么缺点？”
“是个模式就会有缺点的，都有不适用的时候，要辩证地看待问题啊。抽象工厂模式可以很方便地切换两个数据库访问的代码，但是如果你的需求来自增加功能，比如我们现在要增加项目表Project，你要改动哪些地方？”
“啊，那就要至少增加三个类，Iproject、SqlServerProject、AccessProject，还需要更改IFactory、SqlServerFactory和AccessFactory才可以完全实现。啊，要改三个类，这太糟糕了的说。”
“是啊，这是非常糟糕的说。”
“还有啊，就是刚才问你的，我的客户端程序类显然不会只有一个啊，有很多地方都在使用IUser或IDepartment，而这样的设计，其实在每一个类的开始都需要声明IFactory factory = new SqlServerFactory()，如果我有100个调用数据库访问的类，是不是就要更改100次IFactory factory = new AccessFactory()这样的代码才行啊？这不能解决我要更改数据库访问时，改动一处就完全更改的要求啊！”
“改就改啊，公司花那么多钱养你干嘛啊？不就是要你努力地工作吗？100个改动，不算难的，加个班，什么都搞定了。”
“球球蛋，你讲过，编程是门艺术，这样大批量地改动，显然是非常丑陋地做法。我需要地是一个非常优雅地解决方案，我来想想办法改进一下这个抽象工厂模式。”
“好，小伙子，有立场，有想法，不向丑陋地代码低头，那就等你的好消息啦。”

15.7用简单工厂来改进抽象工厂

十分钟后，小菜给出了一个改进方案。去除IFactory、SqlServerFactory和AccessFactory三个工厂类，取而代之的是一个DataAccess类，用一个简单工厂模式来实现。
代码结构图

//DataAccess类
public class DataAccess
{
private static final String	db	= "Sqlserver";

public static IUser createUser()
{
IUser result = null;
if ("Sqlserver".equals(db))
{
result = new SqlServerUser();
}
else if ("Access".equals(db))
{
result = new AccessUser();
}

return result;
}

public static IDepartment createDepartment()
{
IDepartment result = null;
if ("Sqlserver".equals(db))
{
result = new SqlServerDepartment();
}
else if ("Access".equals(db))
{
result = new AccessDepartment();
}

return result;
}
}
//客户端代码
public class Main
{
public static void main(String[] args)
{
User user = new User();
Department department = new Department();

IUser iu = DataAccess.createUser();

iu.insert(user);
iu.getUser(1);

IDepartment id = DataAccess.createDepartment();

id.insert(department);
id.getDepartment(1);
}
}

“大鸟，来看看我的设计，我觉得这里与其用那么多的工厂类，不如直接用一个简单工厂来实现，我抛弃了IFactory、SqlServerFactory和AccessFactory三个工厂类，取而代之的是DataAccess类，由于事先设置了db的值（Sqlserver或Access），所以简单工厂的方法都不需要输入参数，这样在客户端就只需要DataAccess.createUser()和DataAccess.createDepartment()来生成具体的数据库访问类实例，客户端没有出现任何一个SQL Server或Access的字样，达到了解耦合的目的。”
“小菜，你确实很厉害啊，你的改进确实是比之前的代码要更进一步了，客户端已经不需要受改动数据库访问的影响了，可以打95分。为什么不能得满分，原因是如果我需要增加Oracle数据库的访问，本来抽象工厂只增加一个OracleFactory工厂类就可以了，现在就比较麻烦了。”
“是啊，但没木办法啊，这样就需要在DataAccess类中每个方法的if分支语句里面增加了。”

15.8用反射+抽象工厂的数据访问程序

“我们要考虑的就是可不可以不在程序里写明‘如果是Sqlserver就去实例化SQL Server数据库相关的类，如果是Access就去实例化Access相关的类’这样的语句，而是根据字符串db的值去某个地方找应该要实例化的类是哪一个。这样，我们的if就可以对它说再见了。”
“听不懂啊，什么叫去哪个地方找应该要实例化的类是哪一个？”
“我要说的就是一种编程方式：依赖注入（Dependency Injection），从字面上不太好理解，我们也不去管它。关键在于如何去用这种方法来解决我们的if判断问题。本来依赖注入是需要专门的Ioc容器提供，比如Spring.NET，显然当前这个程序不需要这么麻烦，你只需要了解一个简单的‘反射’技术就可以了。”
“大鸟，你一下子说出又是依赖注入又是反射这些莫名其妙的概念，头晕。我就想知道，如何向if或者switch说byebye，至于那些什么概念我都不想了解。”
“心急讨不到好媳妇！急个毛啊？反射技术看起来很玄乎，其实实际用起来不算难。它的格式是Class.forName(className).newInstance();，只要在程序顶端写上import sun.reflect.Reflection;，就可以来引用Reflection，就可以使用反射来帮我们克服抽象工厂模式的先天不足了。”
“具体怎么做呢？”
“有了反射，我们获得实例可以用下面的两种方法。”

//常规的写法
Iuser result = new SqlServerUser();
//反射写法
public class DataAccess
{
private static final String	db			= "SqlServer";
private static String		className	= null;

public static IUser createUser()
{
className = db + "User";
try
{
return (IUser) Class.forName(className).newInstance();
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
}
catch (InstantiationException e)
{
e.printStackTrace();
}
catch (IllegalAccessException e)
{
e.printStackTrace();
}
return null;
}

public static IDepartment createDepartment()
{
className = db + "Department";
try
{
return (IDepartment) Class.forName(className).newInstance();
}
catch (InstantiationException e)
{
e.printStackTrace();
}
catch (IllegalAccessException e)
{
e.printStackTrace();
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
}
return null;
}
}

“实例化的效果是一样的，但这两种方法的区别在哪里？”
“常规方法是写明了要实例化SqlServerUser对象。反射的写法，其实也是指明了要实例化SqlServerUser对象。”
“常规方法你可以灵活更改为AccessUser吗？”
“不可以，这都是事先编译好的代码。”
“那你看看，在反射中可以灵活更换SqlServerUser为AccessUser吗？”
“还不是一样的，写死在代码里面，等等，啊，我明白了。happy啊，我终于看明白这个东东的意思了，因为是字符串处理，可以用变量来代替，就可以根据需要更换了。Happy~”
“你丫才看到，太让我失望了，就像我对你讲四大发明之活字印刷一样的，你现在体会到面向对象带来的好处了吧。”
“嗯，我一下子知道这里面的差别所在了，主要在原来的实例化是写死在程序里面的，但现在用了反射，就可以利用字符串来实例化对象了，而且变量是可以更换的。”
“写死在程序里，太难听了，有点专业精神好不，这叫硬编码。准确地说，是将程序由编译时置为运行时。由于反射中的字符串是可以写成变量的，而变量的值到底是SQL Server，还是Access完全可以由事件的那个db变量来决定。所以就去除了switch或if判断带来的麻烦。”
代码结构图，其中DataAccess类，用反射技术，取代IFactory、SqlServerFactory和AccessFactory。



“现在如果我们增加了Oracle数据访问，相关的类的增加是不可避免的，这点无论我们用任何办法都解决不了，不过这叫扩展，开放-封闭原则告诉我们，对于扩展，我们开放。但对于修改，我们应该要尽量关闭，就目前而言，我们只需要更改private static final String db = "SqlServer";为private static final String db = "Oracle";也就意味着(IUser) Class.forName(className).newInstance();这一句话发生了变化。”
“这样的结果就是DataAccess.createUser()本来得到的是SqlServerUser的实例，而现在变成了OracleUser的实例了。”
“那么如果我们需要增加Project产品时，如何做呢？”
“只需要增加三个与Project相关的类，再修改DataAccess，在其中增加一个public static IProject createProject()方法就可以了。”
“怎样，编程的艺术感体现出现木？”
“哈，比以前，代码漂亮多了。但总体感觉还是有缺憾，因为在更改数据库访问时，还是需要去改程序啊，改db这个字符串的值重编译，如果可以不改程序，那才是真正地符合开放-封闭原则。而且createUser()和createDepartment()的内部实现代码几乎是完全一致的嘛。”

15.9用反射+配置文件实现数据访问程序

“小菜很追求完美嘛！我们可以复用配置文件来解决更改DataAccess的问题。”
“对啊，我可以读取文件来给DB字符串赋值，在配置文件中写明是SqlServer还是Access，这样就连DataAccess类也不用更改了。”
添加一个app.properties文件。内容如下：
DB = SqlServer

//再解析app.properties来获取DB字段值。
public class DataAccess
{
private static String		DB			= null;
private static String		className	= null;
private static Properties	properties	= new Properties();

static
{
try
{
properties.load(DataAccess.class.getClassLoader()
.getResourceAsStream("config/app.properties"));
}
catch (IOException e)
{
e.printStackTrace();
}

DB = properties.getProperty("DB");
}

public static IUser createUser()
{
return (IUser) create("User");
}

public static IDepartment createDepartment()
{
return (IDepartment) create("Department");
}

public static Object create(String name)
{
className = DB + name;

try
{
return Class.forName(className).newInstance();
}
catch (InstantiationException e)
{
e.printStackTrace();
}
catch (IllegalAccessException e)
{
e.printStackTrace();
}
catch (ClassNotFoundException e)
{
e.printStackTrace();
}

return null;
}
}

“哈哈，这下基本上可以得个满分木有啥问题了。现在我们应用了反射+抽象工厂模式解决了数据库访问时的可维护、可扩展问题。”
“从这个角度上说，所有的用简单工厂的地方，都可以考虑用反射技术消除if或switch，解除分支判断带来的耦合。”
“说的好，switch或if是程序里面的好东东，但在应对变化上，却显得老态龙钟。反射技术确实可以很好地解决它们难以应对的变化，难以维护和扩展的诟病。”

15.10无痴迷，不成功

“设计模式真的很神奇哦，如果早先是这样设计的话，我今天就用不着加班加点了。”
“好了，都快l点了，你还要不要睡觉呢？”
“啊，今天都加了一晚上的班，但学起设计模式来，我把时间都给忘记了，什么劳累都没了。”
“这就说明你是做程序员的料，一个程序员如果从来没有熬夜写程序的经历，不能算是一个好程序员，因为他没有痴迷过，所以他不会有大成就，”
“是的，无痴迷，不成功。我一定会成为优秀的程序员。我坚信。”小菜非常自信地说道。