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
1700470310
this.b.doSomethingB（）；
1700470311
1700470312
}
1700470313
1700470314
public void methodC（）{
1700470315
1700470316
this.context.complexMethod（）；
1700470317
1700470318
}
1700470319
1700470320
}
1700470321
1700470322
通过这样一次封装后，门面对象又不参与业务逻辑了，在门面模式中，门面角色应该是稳定，它不应该经常变化，一个系统一旦投入运行它就不应该被改变，它是一个系统对外的接口，你变来变去还怎么保证其他模块的稳定运行呢？但是，业务逻辑是会经常变化的，我们已经把它的变化封装在子系统内部，无论你如何变化，对外界的访问者来说，都还是同一个门面，同样的方法——这才是架构师最希望看到的结构。
1700470323
1700470324
1700470325
1700470326
[
上一页 ]
[ :1.700470277e+09 ]
[
下一页 ]