杂谈设计模式

最近貌似又出现了很多设计模式相关的文章，不过这确实是一个“百谈不厌”的话题。我也来凑下热闹吧，周末闲得无聊来扯扯淡，不要丢我臭鸡蛋。

前两天和朋友去爬香山，走在林荫小道上，看着不高的树枝伸到路上，突然好像回到了“年轻的时候”，就跳起来摸了一下树枝。朋友说笑着说，你长高了。

时空穿越模式

或许说者无心，听者有意。突然脑子里就蹦出国产很多电影里的画面：

一个小孩，往起一跳，然后镜头一换，孩子一下子长高长大了，屏幕上显示一个五年后。。。。

这样的画面应该不少见吧。

山洞奇缘模式

然后由此我又想到很多国产武侠片里的画面：

一个很有潜质的“武学奇才”，被人打落（或者其他原因）到悬崖，然后捡到一本经书（旷世绝学），嗯，这里还会穿插一些奇幻的东东，比如你要对着那个写经书的作者的墓碑磕几个响头，你才是有缘人。

呵呵，对于我们这些看武侠片长大的一代这个镜头应该也见过不少吧。

擦肩而过模式

然后我们看看曾经风靡一时（不知道现在如何）的韩剧里经常出现的镜头

一对本相爱着的恋人，由于发生了什么误会，然后分道扬镳，但是后来又因为什么知道原来这是个误会，等他们互相在茫茫人海里寻找对方的时候，常见的画面出现了：两个人擦肩而过、一个人进电梯一个人出电梯、两个人开着车向着相反方向，嗯，还有用天上的飞机来表现这种场景的。而且，这种场景出现的时候，往往配上慢镜头。

灰姑娘模式

韩剧的说完了，说说台湾偶像剧，台湾偶像剧里就不是某个镜头了，而是整个电视剧都套用一样的基调：灰姑娘和王子相恋，偶然的机会灰姑娘碰上了王子，开始两个人是个冤家，后来慢慢的相爱了，然后中间还会蹦出一个王子的初恋女友啥的，当然，初恋女友是个公主，然后公主用各种很见不得人的手段想得到王子，最后阴谋终于泄露，哦。。。都是这种套路。

模式背后

这些场景一次又一次的出现，但是奇怪的是，观众并没有厌烦。不信，你看看你身边的女友，在她看到两个恋人擦肩而过的时候，她肯定在拍着手喊着，看左边啊看左边啊。

说了这么多，有没有觉得有点面熟？对，这就是模式。看来电影导演早已学会这些模式，而且屡用不爽，只要碰上这样的场景，直接套用这样的模式，基本上可以保证影片建立在一个前人已经论证的成功的经验基础上，不用自己挖空心思构思新的了，如果自己挖空心思再构思，说不定还更容易失败。

软件里设计模式的目的也是一样，碰到这样的场景，可以借助前人的经验，直接套用，不用挖空心思琢磨自己的，觉得更有创意的，说不定自己琢磨个四不像出来，还得不偿失。

但是我们再看看电影导演的拍片模式，虽然要表现的意图（动机）是一样的，但是画面肯定不同，不然就是抄袭了。所以我们在琢磨设计模式的时候也是一样，我们不要死记着那个UML图，更重要的是那段黑话，也就是模式的动机是什么。花更多的精力去琢磨这段话更有价值。然后你再想想，这些所有模式的动机到底是为什么？为什么？为什么？

为什么有这样的动机？其实都是那些原则在为我们指明方向：OCP、DIP、SIP、LSP等等等，所有模式的动机其实都是为了这些原则，那这些原则又是为什么呢？上面的说的一些原则是面向对象的基本原则，然后回归到软件开发的基本原则就是SOC（关注点分离）、高内聚低耦合，那这两个原则又是为了啥呢？为了软件有更好的可维护性。那为啥要更好的可维护性呢？因为需求总是会变，我们又不能抵制变化，那只好拥抱变化，那就是软件开发三部曲：发现变化、封装变化、隔离变化。 

电影模式的背后

我不是学电影的，但是我猜想，电影里面肯定也有《电影设计模式》这样一本书，但是这毕竟是一本书，电影却有千万种，作为一个成功的导演，总不能就抱着这本书吧，那电影里面肯定也有一些指导原则，比如什么视觉冲击（大场面、炫效果等）、观众猎奇心（比如武侠里面的掉悬崖）、或者抓住观众的人性的弱点，电影画面很杯具，博取观众的眼泪（当然，还有夸张搞笑场面，让观众捧腹），等等。那这些原则的目的又是什么呢？有两个：要么获奖，要么票房好。

但是作为一个年轻的导演，想要从零开始，就达到这些指导原则的目标，那就有些 困难了，那年轻的导演最开始的时候就应该先捧着那本《电影设计模式》，先仔细的锤炼这些已经成熟的模式，将这些模式做到融会贯通（先套用，然后理解其精髓，最后融入自己的东西），慢慢的随着拍的电影越来越多，自己经验也就越来越丰富，再来看看那些指导原则，突然发现这么亲切啊，这几年如果遵守了这些原则的电影，基本上有个好票房，或者获奖了，如果没有的，基本上被批做烂片。

两类模式

上面扯淡这么多了，再回到上面的电影里的几个模式，我们发现前三个模式模式和后面一个模式有些稍微的不同，前三个模式一般都是一个场景，最多不过几分钟，而最后一种模式却影响了整个影片的基调。貌似最后一个模式的面更广些。嗯，实际上在软件里我们也有这样的东东，比如我们常说的抽象工厂、策略等等，就相当于这里的一个画面，关注的点很小，实际上Gof23里所提及的模式都属于此类，这类模式更关注的是代码层面的设计问题。还有一类模式，比如MVC、MVP等，却基本上给一个系统定下了一个基调，这就好比前面的灰姑娘模式了，这类模式更多的关注是架构层面的东西，我们可以将其称为架构模式。

如果说Gof23里的模式，关注的是类型之间的关注点的分离，那么架构模式关注的就可能是大的组件之间或层之间甚至是子系统之间的关注点分离。

后记

本篇纯粹扯淡之作，当做周末无聊随便瞎写一点。