最近看Center Tracker , Booking Order 发现webservice公布了不少接口,跟进去看了一下发现有些问题, 比如我们要对数据对象进行添加,修改的操作都发布了独立而且不同的接口, Example :
- AddUser(user)
- ModifyUser(user)
- DeleteUser(user)
- AddOrder(order)
- ModifyOrder(order)
- DeleteOrder(order)
- …
对于不同的对象重复了上面的接口,于是问题出现:
1.接口太多,不好操作
2.无法扩展,新增数据对象就不得不增加接口
如果将来项目扩张,这两点就足以断送我们的项目
所以要在这里说一下Factory & Abstract Factory。 (工厂 ,抽象工厂)这两个模式的应用是在是太普遍了,大家随便Google / Baidu 一下就可以找到一大堆 ,还有那个最为经典的支持多种数据库驱动的例子,我就不在这里啰嗦。
在大多数的工厂的例子中都提出工厂生产产品,工厂会提供一个创建对象的方法,于是结构就是下面这个样子

所以大家通常都会联系通用数据库驱动的那个例子,如果是用SQL,就产生SQL的connection ,command如果是Oracle就产生Oracle 的connection, command (当然ADO,BDE也可以)connection ,command就是产品,可是这个模型对我们上面的那个问题好象没有什么帮助吗!
好了,我们换个思考方向:产品是工厂制造的,那么每个产品都是有制造厂商的不是吗? 看看模型
Ok ,这是什么呢?当然还是工厂模式了,看看我们的接口如何做呢?
Public AddProduct (Product p){
Factory f;
f=p.createFactory();
f.Add(p);
}
Public Modify Product (Product p){
Factory f;
f=p.createFactory();
f.Modify(p);
}
Public DeleteProduct (Product p){
Factory f;
f=p.createFactory();
f.Delete(p);
}
当然我们在合并一下:
public enum Operate {
Add, Modify, Delete
}
Public DataObjectOperate(Product p,o Operate)
{
Factory f;
f=p.createFactory();
if (o == operate.Add) {
f.Add(p)
}
if (o == operate.Modify) {
f.Modify(p)
} if (o == operate.Delete) {
f.Delete(p)
}
};
这么看来我们的webservice接口是不是就只需要DataObjectOperate就可以了呢?
我们将来做扩展,是不是只要新添加的类继承Factory ,继承 Product 就可以了呢?
哈哈,是不是很爽,其实这样的应用非常的广泛,换个角度思考一下我们的程序会变得简单许多..