1700470238
public void methodA（）{
1700470239
1700470240
this.a.doSomethingA（）；
1700470241
1700470242
}
1700470243
1700470244
public void methodB（）{
1700470245
1700470246
this.b.doSomethingB（）；
1700470247
1700470248
}
1700470249
1700470250
public void methodC（）{
1700470251
1700470252
this.a.doSomethingA（）；
1700470253
1700470254
this.c.doSomethingC（）；
1700470255
1700470256
}
1700470257
1700470258
}
1700470259
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
[
上一页 ]
[ :1.700470238e+09 ]
[
下一页 ]