对象级的门面和方法级的门面

 

问题是这么引出的：我们在写Action的时候，要用到一些Service。
第一种方法：按照老的方法，用到哪些Service就注入哪些Service，大不了多写一些setter方法，如下图所示：

 

 

这种做法的优点是：你的Action用到哪些Service很一目了然。但是它的缺点却更明显：首先是code的时候，用到一个新的service你都得写一下setter方法，这对代码结构很不清晰;第二：如果两个或多个Action存在的情况下（一般情况下这是最常见的），那你的代码就更乱了，Action中占主要篇幅的居然是那些getter和setter，主要的有用代码却那么一点点！而且各个Action和Service之间的关系也很乱，看下图：

 

 

第二种方法：引用门面类（Facade），用它把Serive和Action分开。这时会出现一个问题，这个Facade是方法级的还是对象级的呢？
        如果是方法级的，那它里面的方法几乎都是对目标Service的一个引用，如果原来有三个Service，每个Service有四个方法，那这个Facade就得有12个方法！更可怕的是，如果这时再引入一个Service，那改动更多了。
        但是如果这个Facade是对象级的，即它是对Service的引用，而不是对Service的方法的引用，那就好办多了，它只要关心有多少个Service就行，添加一个Service也只是添加一个注入而已，不会改动太多。对象级的Facade唯一一点不足就是，在Action里，可能会出现调用太长的代码，如：this.getXXXFacade().getXXXService().XXX();但这应该不会对我们的设计带来影响。
在使用了Facade后，形成的UML简图如下：

 

 

从图中可以看出，Action和Service层的关系简单多了（其实应该说成：不可见了），Action里也只要有注入Facade就行了，不会出现过多注入的情况。

其实你可能觉得，这种对象级的Facade更像是一个工厂，但名字不重要，只要这符合设计、方便代码、利于重构就行了。