1700470183
设计模式之禅 23.4 门面模式的注意事项
1700470184
1700470185
23.4.1 一个子系统可以有多个门面
1700470186
1700470187
一般情况下，一个子系统只要有一个门面足够了，在什么情况下一个子系统有多个门面呢？以下列举了几个。
1700470188
1700470189
❑门面已经庞大到不能忍受的程度
1700470190
1700470191
比如一个纯洁的门面对象已经超过了200行的代码，虽然都是非常简单的委托操作，也建议拆分成多个门面，否则会给以后的维护和扩展带来不必要的麻烦。那怎么拆分呢？按照功能拆分是一个非常好的原则，比如一个数据库操作的门面可以拆分为查询门面、删除门面、更新门面等。
1700470192
1700470193
❑子系统可以提供不同访问路径
1700470194
1700470195
我们以门面模式的通用源代码为例。ClassA、ClassB、ClassC是一个子系统的中3个对象，现在有两个不同的高层模块来访问该子系统，模块一可以完整的访问所有业务逻辑，也就是通用代码中的Facade类，它是子系统的信任模块；而模块二属于受限访问对象，只能访问methodB方法，那该如何处理呢？在这种情况下，就需要建立两个门面以供不同的高层模块来访问，在原有的通用源码上增加一个新的门面即可，如代码清单23-10所示。
1700470196
1700470197
代码清单23-10 新增门面
1700470198
1700470199
public class Facade2{
1700470200
1700470201
//引用原有的门面
1700470202
1700470203
private Facade facade=new Facade（）；
1700470204
1700470205
//对外提供唯一的访问子系统的方法
1700470206
1700470207
public void methodB（）{
1700470208
1700470209
this.facade.methodB（）；
1700470210
1700470211
}
1700470212
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
[
上一页 ]
[ :1.700470182e+09 ]
[
下一页 ]