由面向对象到设计模式

初入c++时便时常听那些学业上的前辈谈及面向对象编程，直到后来学习c++时用的基础书籍也是名为《面向对象程序设计-c++》，这无处不在的”面向对象“的4字出现的频率很多时候甚至已经超越了c++本身，这也有时提醒我去注意这个捉摸不透的怪家伙~~

多年之前，几个屌丝的程序员再也无法忍受傻逼策划无休止的改需求，奇葩用户各种恶意的测试软件的稳定性，时代发展所带来的不停的软件的更新与扩展，说的这么光明，实际行动的时候却全部都是程序员的加班，坑爹啊呜，为什么受伤的总是程序员~~~~~ ，为了改变这一现状（赚了软件行业这么多桶金却因为加班而没有时间吃喝嫖赌大宝剑简直是是世界上最不公平的事了~），这几个屌丝开始思考自己未来路的规划~~，或是放弃，或是加班，也许是其他~~

世间万物的起始都是有规律可循的，关键在于你是否能发现ta ~~，我始终相信这一点在此之前的多年之前，一群建筑师们聚在一起扪心自问：质量可以客观评价么？换句话说：情人眼中真的会出西施？是否可以从人们的美的理解中提取共识，提取美丽背后所代表的实际的优秀点，美是可以被度量的么？答案的确是肯定的~~，在这里，建筑师所关注的美是建筑的质量，如何设计才可以使建筑更加优秀？一扇门如何设计才是一扇优秀的门？

而在软件系统的设计中：也同样存在这样一个定理，软件的质量是可以被度量和评断的~~

这就显而易见地牵扯出了俩个问题：既然软件的质量是可以被评断的，那么对于软件的质量的高低看法是存在共识的~~，而高质量软件相对于低质量软件他所优秀的地方在何处？而低质量软件相对于高质量软件，又有哪些是高质量软件所没有的？直至此处便得到了以下的结论：既然软件的高低是可以判断的，那么必然我们可以找出一款软件因何而优秀，一款软件因何而拙劣~~~

而之前的那些程序员们也是显然想到这几点，综合这些问题和那些大神们雄厚的项目经验，他们逐渐发觉了一些规律，他们称之为模式，引用《设计模式解析》上面的一句话：模式即是某一背景下某个问题的一种解决方案~~。当然在这里我更习惯于这么解释：某一情况下某个特殊问题关系的结构的特点与处理方法，“每一个模式都描述了一个在我们的环境中会不断出现的问题，并进而叙述了这个问题解决方案的要素”，通过这种方式，解决方案能够百万次地反复应用，但是具体方式又不会完全相同。“

我一直以来都特别喜欢James对于建筑大师Alexander的《The Timeless Way of Buliding》一书中对”模式“基本原理那段文字的解析，堪称对于设计模式的一种灵魂式解读，大家有兴趣的强烈推荐大家去找一下。

对于那段文字：最后得出了如下总结：

一个模式应当具备以下4点：

1：模式的名称

2：模式的目的，即要解决的问题（这一点极其重要，这也是很多萌新错用误用设计模式的源头）

3：实现方法

4：为了实现该模式我们所必须考虑的限制和约束因素

通过这种对于模式的理解，我们从中借由模式看到了观察问题，设计过程和面向对象的更高层次的视角，这也将我们从”细节“中解放出来

还有一点要说明的是：设计模式的本质并不是创造一种新的软件设计问题的解决方法，而是将软件设计界已经存在了的，反映了的优秀的设计经验的方法识别出来；

至于过度处理细节这个问题我将为大家带来一个非常易懂的例子：现在有2个木匠之间讨论“如何为一个橱柜制作抽屉”的问题。

他们的方案分别是：

木匠A：加入为這些橱柜做抽屉，我们需要在木料上直着据下去，然后回转45度再锯，接着再直着锯，再回转45度再锯。。。。。。。。然后就可以了。（听上去就像代码评审，无限的细节，全都是细节！！！）

木匠B：我们应当采用楔形柜或者是方柜？

不知道听到这2个人的话的时候你们会有什么想法，假设听众拥有最基础的建筑学知识，知道最基础的建筑结构。

面对木匠A我相信纵然那人拥有经验也会是蒙逼的，即是他可以听懂每一步所做的事，但是显而易见的他很难从这大块的零散信息中获得这个木匠的目的和意图，（也就是这样做是为了什么？这个结构是什么样子）也就无法对它的想法作出任何评断。

但是面对木匠B就相对地愉悦了太多了，应为他们现在讨论的是一个问题的本质上差别，他们讨论问题的层次更高了，也更加抽象了避免了陷入细节的沼泽。当人们听到木匠B的想法是，头脑中便可以浮现出楔形柜和方柜的特征，同时可以很快的想到这2种柜各自的优缺点，这样设计者们就可以就方案的优缺点进行有效的讨论，而不用关乎那些底层的如何制作木柜的无聊的细节。因为讨论这个问题时目标是明确的。

最后列举一些对于优秀的面向对象策略的基本准则：

1：按照接口编程

2：尽量使用聚合代替继承

3：找出变化并封装之

最近也只有设计模式花了大功夫，写的很撇，不成敬意，仅供娱乐~~~