概念和方法

最近想的越来越多。
十年前不会思考太多，功能完成了就感觉自己完成了自己的工作，后来发现完成是一回事儿，做得好就是另一回事，于是又朝着做得好努力，后来又发现做得好这个东西本身还挺复杂，怎么算好呢？强扩展性？简洁性？
估计拿这个问题去问十个人，会有十一种以上的说法。
但私认为，这个答案应该是唯一的，四个字：
因地制宜。
我们可以用做得很牛逼很复杂的工厂模式去为未来生产不同的可扩展元素打下一个坚实的基础，但如果我们正在做的是一个寸土寸金，每一个字节内存和每一个指令都需要细斟细酌、且对扩展性几乎可以算无要求的驱动时，这么牛逼的工厂模式，则除了鸡肋以外还是鸡肋，一点意义都没有。
我们可以试图实现一个可以在任何条件下正常使用的Singleton，考虑到多线程、销毁顺序等等事情，做一个能用到任何地方的Singleton，可这么做的目的是什么？我们为什么不能在规划阶段就设计好这些元素和流程的相互关系，并且按照时间顺序安排好这些相互关系呢？
设计模式是永恒的经典，但是如果只是逐字逐句、原教旨主义地把它当做马哲一样去研读，那么我们就必将陷入到愚昧的语言所布下的无垠的迷局中，而忽视了它背后更深刻、更重要的禅意。与去做人弹不同，做技术最要不得的就是狂热。在《设计模式沉思录》里面，GOF之一的John Vlissides大师更多地写了一些模式背后的故事，这就是一个入禅的过程。
为什么Java、C#和C++程序员能够坐在一起，讨论同一个叫做设计模式的主题？是因为所有的程序员，无论是哪个行业的工作者，所面临的问题都是一样的：完整且安全地重现需求，并且尽可能地为未来可能的扩展做好足够的准备，而这本身就隐含着环境因素本身。
看过UE3代码后应该很容易就被里面复杂的相关性、耦合度，以及对模式“糟糕”的运用而被激怒。然而当真正用心，一点点揭开每一层包装，每一层面纱后，这种激怒的心情却立刻转变为一种崇拜。代码如同作文，UE俚语般的文字运用，你可以认为它并非文学大师的作品，但却不能不认同这字里行间透出的那些概念。
SceneRenderer、SceneInterface、SceneProxy，是的，每拿出一个代码出来，都觉得应该会有更好的做法，诚然，对于完美的需求刻印在我们每个人的内心深处，无人能够幸免，但这些概念，本身却是强大的。就如同一种信念的支撑，使得引擎无论怎么修改，都不会因为需求的改变而破坏原有的方向和道路。
人们可以因为概念而否定手段，但却不能因为手段去否定概念。正如同做网页用不上工厂模式，宣告不了设计模式的穷途末路一样。禅就在那里，装作看不见，它还在那里。
于是软件做到了最后，工具掌握到了一定程度，突然可能会发现，我们曾经追求的那些东西，他们本身还是那么完美，只不过我们曾经使用了一种错误的观点和认识，沿着一条错误的道路，去认识这些东西本身。
近日在折腾数据绑定的实现，同一个数据绑定的概念，WPF实现是一种做法，UE3实现也是一种做法，而我们自己却还可以选择其他的做法来完成同样的目的。但，一说到数据绑定，你知道是什么，我也知道是什么，这就是概念的作用。设计模式云云，不正是这个东西？
软件到了最后，玩的不也就是这些东西？
按照大师的话说：The Design of design。
判别概念——分析环境——进行设计。
switch-case实现的工厂，难道就不能叫做工厂？必须抽象Factory基类和Product基类的才叫工厂？
Global变量、Global方法就不能理解成Singleton？你让C语言程序员情何以堪？
做法没有任何意义，在一个地方正确的做法，在另一个地方很可能就是错的。
只有隐藏在做法背后的概念、理念，才是真正应该追求的东西。
而一个设计，先要保证其概念是正确的，去讨论其做法才有必要。概念本身就漏洞百出的东西，再多原教旨主义的设计模式也救不了。
说到底，任何软件都只是一种商业产品，与其追求那些细枝末节，不妨先考虑考虑软件本身的那些“概念”是否经得起推敲。
因为……这已经早已不是一个只要做出来就行的时代了……