设计模式的初衷---“委托”有感

Posted 2021-02-20 sabre

很多设计模式的初衷，是“尽量少地修改既有代码”，能不动的，就不要去动。但是，如果你发现要实现新的需求，就不得不去修改既有代码，就说明这段代码该修改了。

例如，对于一个方法来讲，如果每当增加某个类别时，就需要修改这个方法，那么就不太对劲儿，也就是散发出“臭味儿”的时候，就是需要使用设计模式的时候。

很多设计模式，初学者无法理解，是因为还没有遇到那种场景。此时，一个合格“布道者”应当把那个场景描述出来，让初学者真正理解为什么应当使用这种模式，同时，要列举出来如果不使用这种模式，会生产哪些问题。而不是来一句“你以后就懂了”、“用多了就懂了”，这样的回复，没有任何意义。这样回复的人，其实自己没有真明白，似乎萦绕于心，但讲不出来，而能讲出来的才是真正理解。

很多初学者无法理解“委托”到底是干嘛用的。

这篇文章https://www.cnblogs.com/jimmyzhang/archive/2007/09/23/903360.html，讲得很清楚，但是如果不明白设计的初衷，仍然会觉得多此一举。

目前的理解，使用“委托”或“指针”的原因之一是“尽量少地修改既有代码”，提高封装度，降低耦合度，符合开闭原则（对扩展开放，对修改关闭，也就是可以扩展，但不允许修改）。

根据这篇文章所举的示例，如果不使用委托，那么每次有新的语言类别进行问候时，都要去修改GreetPeople(string name, Language lang)方法，增加if-else或switch的分支。有些人或许认为，这不算什么，工作量又不大。但这就是“坏味道”，这就是系统变得混乱的开始。极端一点，如果我们的系统是给全世界的人用的，全世界有多少种语言呢？据前德意志民主共和国出版的《语言学与语言交际手段指南》一书上说，当今世界已知语言共有5651种，公认的独立语言有4200种，其中100万以上人口使用的有19种。这个if-else或switch应该有多少个分支？

重要的是，这是一个坏的设计，耦合性太高，扩展性很差。想要扩展时，就必须要修改源码，无法独立封装。