1700470160
设计模式之禅 23.3.2 门面模式的缺点
1700470161
1700470162
门面模式最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放，看看我们那个门面对象吧，它可是重中之重，一旦在系统投产后发现有一个小错误，你怎么解决？完全遵从开闭原则，根本没办法解决。继承？覆写？都顶不上用，唯一能做的一件事就是修改门面角色的代码，这个风险相当大，这就需要大家在设计的时候慎之又慎，多思考几遍才会有好收获。
1700470163
1700470164
1700470165
1700470166
1700470167
设计模式之禅 23.3.3 门面模式的使用场景
1700470168
1700470169
❑为一个复杂的模块或子系统提供一个供外界访问的接口
1700470170
1700470171
❑子系统相对独立——外界对子系统的访问只要黑箱操作即可
1700470172
1700470173
比如利息的计算问题，没有深厚的业务知识和扎实的技术水平是不可能开发出该子系统的，但是对于使用该系统的开发人员来说，他需要做的就是输入金额以及存期，其他的都不用关心，返回的结果就是利息，这时候，门面模式是非使用不可了。
1700470174
1700470175
❑预防低水平人员带来的风险扩散
1700470176
1700470177
比如一个低水平的技术人员参与项目开发，为降低个人代码质量对整体项目的影响风险，一般的做法是“画地为牢”，只能在指定的子系统中开发，然后再提供门面接口进行访问操作。
1700470178
1700470179
1700470180
1700470181
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（）；
[
上一页 ]
[ :1.70047016e+09 ]
[
下一页 ]