设计模式之吾解

设计模式的创造者和发现者并不是GoF（Gang of Four，《设计模式》的作者），他们只是把这些东西系统化了一下，给整合在了一起，命了个名字而已。
        没错，能把他们系统化起来，再归结到一本书里面，已经很牛了，更不用提《设计模式》对几代程序员/工程师的影响了。
        可是，任何事物都是有两面的，模式的出现是在很大程度上提升了项目的开发效率和软件的工程化水平，使得程序设计方法有了依据可循。但同时带来的问题是对于模式的滥用：为了设计模式而设计模式的过度设计比比皆是，开发效率因而随之下降，并且引入模式之后增加了问题及程序的复杂度，使得扩展/优化/修改变得会非常困难。
        这并不夸张，ED们不经常出现这种情况么？

        那么，要避开这些问题，就要首先正视模式。
         软件设计中最重要的演变就是抽象化程度的不断提高：把共同的指令流抽象化，就变成了过程；把相关的数据抽象结合在一起，就变成了抽象的数据类型/数据结构；再进一步深度抽象：提取出抽象数据类型的共同部分，就产生了继承/封装的面向对象（OO）。
        设计模式是更高一级的软件抽象：对于OO的构建方式的深度抽象。但是，如同在没有模式之前出现的各种方法仍然只是新方法一样，模式也并不是必须的：在GoF出书之前仍然可以解决软件设计所面对的所有问题。你不必知道什么是Singleton、什么是Provider、什么是Factory，你所做的本来就是发现问题、分析问题、然后解决问题，然后继续发现问题，或者是使用分治法来一步步解决大型问题。
        但不久之后，软件开始工程化了，变得复杂了，程序员之间的协作要求变高了，需要统一的规范和协定了；不然面对鱼龙混杂的Code和Coder，只可能更多的时间都在读代码而不是写代码。架构师的出现是解决这个问题的一个很好的方法，另外一个方法就是模式了。模式提供的是规范之外的一个基于代码层面懂得约束和协定：当两个不同的开发者对待同样一段代码时，都会对它进行同样的解释和使用，对待同样一个问题的时候，都会提供一个相似的解决方案。所以，这种约束既同步了不同程序员之间的解释，又能够让程序员对代码的使用和构造大致符合一个公共协定，而只需要了解这个公共协定就能够直接使用该段代码的接口并无需了解其实现，代码的复用性大增。

        但回过头来看，如果你只是在写一个小东西，或者是几个人完成一个比较小的项目，或者是在编写你所负责的模块的内部代码（不许要对其接口开放），如果在这之中只要一个控制全局状态的对象，那么，一个注释明确见名知义又好记又好用的全局变量完全能够代替Singleton模式。因为，这并不需要约束，你和同伴都知道他是什么，而且简单的方法简单实现，反而会易于理解，并且还会避免引入模式后的复杂度。一行代码和六个模式结合都可以实现输出“Hello, world!”，你更喜欢哪一个？
        模式并不是必须的，特别是在引入后会绕更多弯的情况下。
        如果可以，请用最直接的方法。