设计模式赖以实现的基础：抽象

设计模式赖以实现的基础：抽象

    最近看设计模式这本书，感觉抽象是大都数模式赖以实现的基础。这里只不过写写小感想。

    看这本书的感触说得肉麻些：为学习新的模式喜悦，为一时没办法领悟一些实现背后的思想忐忑。

    不知道大家看技术书籍特别是代码设计类的书是不是都有这样的感觉：一些自己认为奥妙的地方反而没有半点说明。

    好比牛顿发现了地心引力但只告诉你重力加速度是多少没告诉你他是怎么想到会有地心引力这东西的。上学时候即使最详细的教科书也有无法表达的死角，也许是有意不告诉你也许是人类语言的缺陷反正这些东西总在你对另外一些东西熟能生巧以后才能有所感悟。

    书里例举的代码浅显易懂，单单模式本身很容易理解，书里也只告诉读者该模式解决了什么问题，怎么实现，效果如何，该在什么时候使用。但细想为什么会创造出或总结出这种模式就感觉背后的思维很精妙。博弈、权衡，最后选择最理想的抽象模式来解决问题？

    抽象的东西似乎离艺术不远。《代码之美》、《编程艺匠》 、《编程之道》、《编程之禅》，艺匠来形容编码大师很恰当：除了像匠人一样掌握大量的开发技巧和工具、拥有丰富无比的经验，还和艺术家一样在现实与实现中寻找平衡。

    扯远了回到设计模式中的抽象。

    在代码中，语言的抽象特性带来的好处是使接口简洁，避免重复代码的产生，代码的耦合，避免代码的复杂程度，这些熟悉面向对象编程的应该多少都有体会。在现实中许多事物也能抽象出共同特征，还有它们之间的本质联系，模式中的很多抽象都体现了这里两个作用，这些抽象建立起来的模型让模式很优雅地处理对象间的关系，很轻松地完成了任务，也让代码有很好的弹性。

    举个例子，设计模式介绍了解释器模式（印象这个模式在C++沉思录里面也有介绍）， 解释器的使用场景之一是把一条编程语句内的各元素提取出来，然后完成该语句的计算。它很好地抽象出各个元素（比如操作符，操作数，还可能是这个语句中包含的子语句）的特征（都包含一个计算结果）与它们之间的关系（处理的时候都调用统一的接口，具体子类负责具体的计算）。我刚开始学编程的时候打算实现一个简单的计算器，当初对面向对象只有粗浅的概念，用的是过程式代码，最终没有从自己给自己制造的麻烦中解脱出来，可耻地失败鸟，现在我认为这也是一个很适合用解释器模式来处理的问题。

    模式的起因

    到目前我感觉书中介绍的设计模式一共解决了两个层面的问题。

    一个是编码本身的问题，比如接口模式（有时只是简单地封装过程式代码，统一接口避免耦合与代码错误）和单例模式（避免命名冲突，保证任何使用这个类的地方数据同步）。

   另外一个是对现实进行建模，就好比刚才举的解释器的例子。

    模式起因也在这2个层面中。

    编码时有一些明显的标志来使用继承，开发中可能会因为出现这些标志才意识到该使用一些解决编码问题的模式。

    对现实的建模一般都在编码之前，感觉这部分最难最深奥，编码时要么用一堆零件都没能把模型建立起来，要么只用了很少的零件就搭建了完美的解决方案，之间没有平滑过度。个人感觉而已。