1700470113
//提供给外部访问的方法
1700470114
1700470115
public void methodA（）{
1700470116
1700470117
this.a.doSomethingA（）；
1700470118
1700470119
}
1700470120
1700470121
public void methodB（）{
1700470122
1700470123
this.b.doSomethingB（）；
1700470124
1700470125
}
1700470126
1700470127
public void methodC（）{
1700470128
1700470129
this.c.doSomethingC（）；
1700470130
1700470131
}
1700470132
1700470133
}
1700470134
1700470135
1700470136
1700470137
1700470139
设计模式之禅 23.3 门面模式的应用
1700470140
1700470141
23.3.1 门面模式的优点
1700470142
1700470143
门面模式有如下优点。
1700470144
1700470145
❑减少系统的相互依赖
1700470146
1700470147
想想看，如果我们不使用门面模式，外界访问直接深入到子系统内部，相互之间是一种强耦合关系，你死我就死，你活我才能活，这样的强依赖是系统设计所不能接受的，门面模式的出现就很好地解决了该问题，所有的依赖都是对门面对象的依赖，与子系统无关。
1700470148
1700470149
❑提高了灵活性
1700470150
1700470151
依赖减少了，灵活性自然提高了。不管子系统内部如何变化，只要不影响到门面对象，任你自由活动。
1700470152
1700470153
❑提高安全性
1700470154
1700470155
想让你访问子系统的哪些业务就开通哪些逻辑，不在门面上开通的方法，你休想访问到。
1700470156
1700470157
1700470158
1700470159
1700470160
设计模式之禅 23.3.2 门面模式的缺点
1700470161
1700470162
门面模式最大的缺点就是不符合开闭原则，对修改关闭，对扩展开放，看看我们那个门面对象吧，它可是重中之重，一旦在系统投产后发现有一个小错误，你怎么解决？完全遵从开闭原则，根本没办法解决。继承？覆写？都顶不上用，唯一能做的一件事就是修改门面角色的代码，这个风险相当大，这就需要大家在设计的时候慎之又慎，多思考几遍才会有好收获。
[
上一页 ]
[ :1.700470113e+09 ]
[
下一页 ]