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
1700470328
设计模式之禅 23.5 最佳实践
1700470329
1700470330
门面模式是一个很好的封装方法，一个子系统比较复杂时，比如算法或者业务比较复杂，就可以封装出一个或多个门面出来，项目的结构简单，而且扩展性非常好。还有，对于一个较大项目，为了避免人员带来的风险，也可以使用门面模式，技术水平比较差的成员，尽量安排独立的模块，然后把他写的程序封装到一个门面里，尽量让其他项目成员不用看到这些人的代码，看也看不懂，我也遇到过一个“高人”写的代码，private方法、构造函数、常量基本都不用，你要一个public方法，好，一个类里就一个public方法，所有代码都在里面，然后你就看吧，一大坨程序，看着就能把人逼疯。使用门面模式后，对门面进行单元测试，约束项目成员的代码质量，对项目整体质量的提升也是一个比较好的帮助。
1700470331
1700470332
1700470333
1700470334
1700470336
设计模式之禅 第24章 备忘录模式
1700470337
[
上一页 ]
[ :1.700470288e+09 ]
[
下一页 ]