1700470213
}
1700470214
1700470215
增加的门面非常简单，委托给了已经存在的门面对象Facade进行处理，为什么要使用委托而不再编写一个委托到子系统的方法呢？那是因为在面向对象的编程中，尽量保持相同的代码只编写一遍，避免以后到处修改相似代码的悲剧。
1700470216
1700470217
1700470218
1700470219
1700470220
设计模式之禅 23.4.2 门面不参与子系统内的业务逻辑
1700470221
1700470222
我们这节的标题是什么意思呢？我们举一个例子来说明，还是以通用源代码为例。我们把门面上的methodC上的逻辑修改一下，它必须先调用ClassA的doSomethingA方法，然后再调用ClassC的doSomethingC方法，如代码清单23-11所示。
1700470223
1700470224
代码清单23-11 修改门面
1700470225
1700470226
public class Facade{
1700470227
1700470228
//被委托的对象
1700470229
1700470230
private ClassA a=new ClassA（）；
1700470231
1700470232
private ClassB b=new ClassB（）；
1700470233
1700470234
private ClassC c=new ClassC（）；
1700470235
1700470236
//提供给外部访问的方法
1700470237
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所示。
[
上一页 ]
[ :1.700470213e+09 ]
[
下一页 ]