程序设计模式-“OPGA设计模式”简介
2013年11月10日

程序设计模式-“OPGA设计模式”简介
即(One Parameter Go Anywhere)“一参走天下”


这是个新想法,看起来很不错。能够解决我们在编程时,要考虑太多的参数传递和回传的问题。如果能实现一种模式,让我们无须传递这么多参数,那是多么的好啊!

 

先看看,我们编程中经常会遇到的问题:

 

1、要求Service回传多个信息

可行的做法:

public ResultBean doService(xxx){}


定义一个返回的ResultBean,用于存放返回的多个信息

 

2、要求把一堆参数交给下一个方法去处理

 

比如,如下代码:

public ResultBean doService(String taskType, String timerAttr,

                           List<FormVO> formAttrs, List<OthersVO> otherAttrs,

                           String taskName, String serviceId, String orgIDString userID)

 

或者把参数全都封装成一个bean,如下:

public ResultBean doService(StatReqBean bean)

 

第一种呢,参数倒是传递了,但是用起来不给力,特别是链式传递(比如说上面的doService方法用完之后,又把这些参数传给一个叫xxxDAO的方法),又要传这么多参数,麻烦。参数你就不能少一点吗?没办法啊,程序有这么复杂啊,Service层或者Dao层人家就需要这些参数,你怎么办?

 

第二种呢,其实更“科学”一点,唯独有一点不好的是,每次都要定义各种bean,请求有请求的各种bean,返回有返回的各种bean。(比如在航空公司B2B平台项目中,习惯的是请求的bean命名为XxxReqBean,导致一大堆XxxReqBean,返回的bean命名为XxxRespBeanXxxRespBean也是一大堆)。

 

很早以前,我还没用Struts 12,那时用纯ServletJSP做开发,表单参数一大堆,要是想把这些参数传递到Helper类去处理,比如校验,就要传递很多参数,麻烦!

 

后来用上了Struts的表单自动封装到VO的功能,把数据都定义成一个VO,然后这个VO对象,就可以方便的传到程序的各处了,不管是传到Helper类去处理,还是传到ServiceDao中,都是很方便的。

 

现在Spring盛行,我们又学到了很巧妙的一招——BeanFactoryApplicationContext、……即,我们可以把需要的东西放到一个bean容器中,要什么就拿什么。通过beanidname)去获取bean

 

当然,这个容器需要一些通用性,要能“海纳百川”。

 

好,思路就是这样。我们需要定义一个通用的bean容器

 

我将它命名为:BeanSet

 

设计目的:可以轻松add一个对象,然后轻松get出来。

 

那么,现在参数传递的方法,参数都可以统一了,写法如下:

 

public void doService(BeansSet beans){}

 

看到没,我们参数统一为BeansSet,这里面可以装任何我们想要的参数,获取也很简单,只需要调用beans.get( id )即可。聪明的你,也许会想到,这个BeansSet怎么这么神奇呢,不会全部都是存的Object对象吧,到时候还要强制转换对象类型,是不是比较麻烦,而且效率低。

 

呵呵,这些问题,设计者早就已经想到了,咱们既要易用,又要高效!

 

自从JDK 1.5之后,泛型是被推荐使用,JDK能非常高效地支持泛型!

 

于是,我通过泛型,实现了类型自动aware的功能

 

BeansSet里面装了BeanObject<?>,这是个泛型的对象,在new的时候指定其对象类型,比如:

BeanObject<String> nameObj = new BeanObject<String>(id, value);

 

其实,BeanObject也是一个容器,它里面可以存储一个特定类型的Java对象实例。通过getObject()方法获取对象的实例(称之为value)。还有一个id,也就是这个对象的名称。通过getId获取。还有一个getType()方法,可以获取该ObjectClass类型。

 

比如String name = "zollty"; 这个name参数,我们要把它装载到BeanObject中:

BeanObject<String> nameObj = new BeanObject<String>("name", name);

 

然后加入BeansSet里面,

beans.add( nameObject );

 

现在看,本文的标题,叫做“OPGA设计模式”,“一参走天下”。

 

这个BeanObject组装好了之后,就可以传给其他程序了,其他程序中去拿自己需要的bean

 

我们经常头痛的问题又来了,一个方法可能有多个方法名相同,但是参数个数、类型不同的情况。假设有4个参数,如果要提供全面的构造函数,那要写4的排列组合数(即4*3*2*1=24)个构造函数,而且java相同类型和参数个数的方法或构造函数是不被允许的,所以即使你想写24个构造函数,除非是4个类型各不相同的参数,否则,还不支持这么多构造函数或方法。

 

比如

 

// 两个参数

public Result fileUpload(Request request, String dir) {

fileUpload(request, absDir, null, null); // 调用4参的方法,用两个null参数

}

// 三个参数

public Result fileUpload(Request request, String dir, String suffix) {

fileUpload(request, absDir, null, inludeSuffix);

}

// 四个参数

public Result fileUpload(Request request, String dirint len, String suffix, String mimeType) {

fileUpload(request, absDir, null, inludeSuffix);

}

大家是不是经常见到这种代码,你用起来是很方便,有时只用两个参数的,某些情况又可能用三、四个参数的。但是对于写API的人来讲,太麻烦了,还要写这么多个不同参数的方法,真是麻烦!

 

这个还不算什么,最坑的是,有一次我们被坑惨了,本来是一个很小的改动(修改了一个接口,为一个方法增加了一个参数而已),但是要通知所有的接口调用者统统修改他们的代码。造成了多少人力和时间的消耗?比如

public interface IService{

    Result doProcess(String appid, List data, User user);

}

 

现在,改了接口,给doProcess方法多加了一个参数orgid,如下

Result doProcess(String appid, List data, User user, String orgid);

 

这一改是“牵一发而动全身”啊!,别人以前的代码继承了这个接口,现在全是一堆红叉,报错:未实现接口的所有方法!

 

有了“OPGA设计模式”,就可以基于一种惯性的编程习惯:我们只传一个参数——BeansSet,比如:

 

void doProcess(BeansSet beans);

 

何时何地,我们都传一个参数!因为它是万能的。这是“一参走天下”的第一层含义。

 

这样,我们也不会像上面所遇到的那种情况,去改接口,然后其他实现类都报错。

 

我们基于一个原则:“服务者”只需要把值传给“被服务者”,至于哪些值要用,哪些值不用,“服务者”根本不用关心。同理,“被服务者”按需去取它需要的东西,用到哪些取哪些,至于有没有,取了再说。


注意,我们可以Result对象也省了,因为它也被BeansSet对象取代了,返回的结果也存在BeansSet中。这样,方法从调用,到全部执行完,算是一个周期。在这个周期中,BeansSet可以全线通吃的。这是“一参走天下”的第二层含义,它可以贯彻到一个方法的整个执行线路。


这种设计模式,我刚开始还不是很习惯,但现在我越用越顺手了,它的好处就是基于一种良好的习惯。现在,又发现了很多的好处,比如:

 

有些方法要throw Exception,但throw Exception这个动作,是和“终止程序运行”绑定了的,也就是说throwException,方法也就返回了。但有时候,我们希望在throw了一些非核心的Exception的情况下,程序不返回,依然继续往下运行

如果throw Exception的话,意味着我们只有两种状态:要么完全成功,要么完全失败!我现在要多加几种状态,在方法中可以保存多个错误信息,全部都放到BeansSet中,比如throw WarnExp1WarnExp2ErrorExp1FatalExp1,把这些信息都回传回去,同时也可以传一个isSuccess的标识,非常简单,只需要添加到BeansSet中去就可以了,比如:

 

beans.add( new BeanObject<Boolean>("isSuccess", false) );

 

上层如果需要,它可以查看“有没有成功啊,有没有轻微错误和警告啊,有没有造成严重影响的Fatal错误啊”


小伙伴们,读完动手试试吧。用多了,你会真正喜欢上这种设计模式的。它不是强制性的编程要求,你可用可不用。但是多了一个解决方案,而且是实用的解决方案,总算是一件好事!而且这个设计模式的强大,连作者自己都还未完全发掘,上面那些例子,只是凤毛麟角、普通应用,说不定还能够衍生出一些很Nice的功能!