滥用模式；设计模式和直接了当之间的矛盾

一) 滥用模式

 

 在 head first 设计模式中有这样一段对话：

最少知识原则：只和你的密友交谈。

问：还有另外一个原则叫做 Law of Demeter，它和最少知识原则之间有什么关系？

答：其实这两个名词指的是同一个原则。我们倾向于使用最少知识原则来称呼它是因为以下两个原因：

1)这个名字更直接。

2)法则给人感觉是强制。

事实上，没有任何原则是law，所有的原则都应该在有帮助的时候才遵守。所有的设计都不免需要折中（在抽象和速度之间取舍，在空间和时间之间平衡。。。）。虽然原则提供了方针，但在采用原则之前，必须全盘考虑所有的因素。

 

 

 

中国有句老话：“过犹不及”。从作者上面的话看来，只有在欠当的使用使用设计模式才更有威力。

那么在什么时候才应该使用设计模式那？看来好像是个不太容易回答的问题。也许这个问题随着设计经验的深入，对设计模式认识的深入，才会有更明晰的结果吧。

 

熟知“三十六计”的人应该还是有不少的，但是能够运用自如的人也许并不不在多数。 也许只有那些真正领悟了“三十六计”精髓的人们，那些多学多用，熟能生巧的人们才能使用得得心应手吧？

 

 

二) 设计模式和直接了当之间的矛盾

问：采用最少知识原则有什么缺点嘛？

答：是的。虽然这个原则减少了对象之间的依赖，研究显示这回减少软件的维护成本，但是采用这个原则也会导致更多的“包装”类被制造出来，一处理和其他组件的沟通，这可能会导致复杂度和开发时间的增加，并降低运行时的性能。

 

 

设计模式为了提高代码的可重用性和易于维护，其中的很多原则：想了很多方法，增加了很多马甲来“隔离变与不变”，“对扩展开放，对修改关闭”，“最少知识原则”等等。

采用设计模式后，在阅读代码时会感觉左拐右拐，为了做某件事情，貌似增加了很多无用功，婆婆妈妈，扭扭捏捏的，不是直接拼刺刀那么爽快淋漓。

 

我以前常用c语言，基本上是面向过程编程。刚开始接触和阅读C++, 遵循oo编程思想的代码时。总觉得代码的调用流程不够直接，因为c++的“多态”特性，很多调用流程在代码上看起来没有c语言那么明晰(当然在c语言中照样可以使用到一些设计模式思想)，让人在阅读代码时觉得很不爽，摸不着头闹，O(∩_∩)O哈哈~

 

但当你阅读了设计模式后，认识改观了很多。