夜游长空

设计模式，实际上是一些很标准的算法解决方案，如果对于一个很常见的问题，一个人使用了设计模式中的方法解决，当别人看代码的时候，也会很爽快。而如果没有，那看代码的人就会很疑惑，问题明明可以很明确的使用某种设计模式解决，那为什么原来是这样的呢？是不是有什么tricky的地方，不得不这样写？无形中延长了时间，并且增加了维护时出问题的机会。

我觉得知道各个模式所表达的算法实现各个设计模式所需要的算法还算容易，而明确的知道什么时候该用什么模式就比较难了。我也经常写出自己后悔的代码来：在写过代码后，review的时候，突然发现，其实可以用更好的方法解决问题。这就是refactoring的作用了吧。呵呵。

二、Singleton, Builder, Prototype模式

这三个模式仍然是关系到对象创建的，但这三个模式特点都很明确，比较容易找到适应的情形。再来讲三个故事：

1、从前，有一个小姑娘叫“春”（这是我高中的时候，一个同学作文中经典的句子，很难忘记~）。我们叫她“春姑娘”吧。有一天她在海边散步的时候，见到了一个油灯，上面写着“Singleton”，小姑娘很好奇，就轻轻摸了一下这些字，突然从灯里面出来了一个灯神，他跟小姑娘说：“谢谢你帮我解除了咒语，我现在自由了。只要你拿着这个灯，什么时候叫一句‘Singleton’，我都会出来。” 小姑娘有些犹豫，我不会喊来坏蛋吧？这个灯我又不熟悉。灯神大笑，这个灯叫“Singleton”，所以每次出来的都只能是我，不会是别人的。甚至替身都不会有。小姑娘高兴的回家了。

2、其实，小姑娘在家里很苦。受到继母的虐待。每天都要做饭，洗衣服，挑水，天不亮就要干活，一直要干到深夜。这天晚上，终于干完了活，睡觉之前，她把灯神交出来，想跟他聊聊天。因为她找不到别人聊天了，能找到的只有这个向她承诺过的灯神了。她把她的苦恼都跟灯神说了，灯神很同情她。（其实，这个灯神就是天界众神派来帮助小姑娘的）临走的时候，送给小姑娘一口锅，上面写着Builder这个单词。小姑娘不解，我现在还有锅啊。灯神说，这个锅是天界众神使用的锅，它的最大特点就是不用人干预就可以做出饭菜。你只需要按照这个菜谱往锅里放进原料，盖上盖子，等一会再打开，就是香喷喷的饭菜了。说着给了小姑娘一本菜谱。

3、自从有了那口神奇的锅，小姑娘的劳累减轻了很多，继母很生气。她又命令小姑娘每天要到海边钓鱼，而且必须钓到十种鱼，每一种鱼100条，这100条鱼必须颜色重量形状都要一样，否则不算。小姑娘哭着说：“这不可能啊~“ 继母狠狠地说：”怎么不可能，钓不完就别回家！“ 小姑娘来到海边，坐在岸上哭了起来。这时，灯神又神秘的出现了。他送给小姑娘一根鱼竿，并说，这个鱼竿是天界众神的鱼竿，这个鱼竿叫’Prototype’（天界众神是研究Design Pattern的~），只要是它钓到的鱼，你只要喊：”Clone!“ 就会复制出一个跟这条鱼各个方面都一样的鱼。最终，美丽善良的小姑娘在灯神的帮助下，通过水晶鞋事件，与王子结为夫妻，过上了幸福的生活。

这三个模式从字面上都可以看出来是做什么用的：

Singleton Pattern: 中文叫”单件“，顾名思义，就是说只允许有一个实例的对象，而且无论在哪里都可以拿到这个实例。优点是最简单的满足了单一实例的要求，不足之处就是，在哪里都可以拿到，就跟静态变量一样，容易让程序混乱，而且对多线程也是一个挑战。

Builder Pattern: 隐藏构造复杂对象的过程，用户只需要将构建复杂对象的基础对象提供给Builder，就可以得到最终的结果。我们用的输入法实际上就是一种Builder。

Prototype Pattern: 这个模式对于现实生活来说，有些神奇（现在也不是了，因为有了克隆技术），但是对于写程序来说，应该不陌生了。Java, C#等等，都内置了这个Pattern，那就是对象的Clone方法。可以通过一个原形对象，创建出一个与之状态完全一样的对象。与Factory不一样的地方就是，能够保证状态。

创建型模式一共六个，就复习完了。用了一个周末的时间（两个半天）。

Update：一位兄弟指出我把算法和设计模式混淆了。我想了一下，确实是不妥，因为设计模式是在设计阶段考虑的问题，而算法是在实现阶段考虑的问题，不应该混为一谈。不过设计的如何，最终要使用算法来实现。所以我认为设计模式和实现它的算法是密不可分的（否则就不会有那么多本书分别介绍C#, Java等等中的Design Pattern了），而且对于一个开发人员来说，设计和开发更是紧密结合的。