打字猴:1.70047026e+09
1700470260 还是非常简单,只是在methodC方法中增加了doSomethingA()方法的调用,可以这样做吗?我相信大部分读者都说可以这样做,而且已经在实际系统开发中这样使用了,我今天告诉各位,这样设计是非常不靠谱的,为什么呢?因为你已经让门面对象参与了业务逻辑,门面对象只是提供一个访问子系统的一个路径而已,它不应该也不能参与具体的业务逻辑,否则就会产生一个倒依赖的问题:子系统必须依赖门面才能被访问,这是设计上一个严重错误,不仅违反了单一职责原则,同时也破坏了系统的封装性。
1700470261
1700470262 说了这么多,那对于这种情况该怎么处理呢?建立一个封装类,封装完毕后提供给门面对象。我们先建立一个封装类,如代码清单23-12所示。
1700470263
1700470264 代码清单23-12 封装类
1700470265
1700470266 public class Context{
1700470267
1700470268 //委托处理
1700470269
1700470270 private ClassA a=new ClassA();
1700470271
1700470272 private ClassC c=new ClassC();
1700470273
1700470274 //复杂的计算
1700470275
1700470276 public void complexMethod(){
1700470277
1700470278 this.a.doSomethingA();
1700470279
1700470280 this.c.doSomethingC();
1700470281
1700470282 }
1700470283
1700470284 }
1700470285
1700470286 该封装类的作用就是产生一个业务规则complexMethod,并且它的生存环境是在子系统内,仅仅依赖两个相关的对象,门面对象通过对它的访问完成一个复杂的业务逻辑,如代码清单23-13所示。
1700470287
1700470288 代码清单23-13 门面类
1700470289
1700470290 public class Facade{
1700470291
1700470292 //被委托的对象
1700470293
1700470294 private ClassA a=new ClassA();
1700470295
1700470296 private ClassB b=new ClassB();
1700470297
1700470298 private Context context=new Context();
1700470299
1700470300 //提供给外部访问的方法
1700470301
1700470302 public void methodA(){
1700470303
1700470304 this.a.doSomethingA();
1700470305
1700470306 }
1700470307
1700470308 public void methodB(){
1700470309
[ 上一页 ]  [ :1.70047026e+09 ]  [ 下一页 ]