Introduction
现在，我还能回想起上五年级的那段时间，我和我的朋友常常在教室里摆弄几台老师为了尽可能给予我们良好的启蒙所购置的计算机。那些机器的磁盘驱动器已经损坏，因此我们不得不用双手将想要运行的程序输入电脑中，所以我从那时候就更加偏爱简短的程序，就像下面这样：
10 PRINT "BOBBY IS RADICAL!!!"
20 GOTO 10
但即使如此简短，由于我们缺少专业的编程知识，无法在程序出问题时进行定位和解决，运行程序这件事情对我们来说更像是某种冒险游戏。
我们在代码书架背后发现了一个怪物，那是由几十张密密麻麻的代码所组成的程序，我们好不容易才鼓起勇气尝试运行它，结果发现其内容看起来非常的荒诞 -- 程序的标题是“Tunnels and Trolls”，我们都不知道它是干什么用的，但是听起来像是个游戏 -- 没有什么事情比亲自开发一个游戏程序更酷的了。
后来我们怎么也没能运行它，在那一年以后，我们搬出了那个教室（后来当我有了一些基础，我才明白那个程序仅仅是一个棋盘游戏的一部分，用于生成字符）。但那时一切已成定局 -- 从那时起，我就想成为一名游戏开发者。
在我十几岁的时候，家里有了一台装备着 QuickBASIC 的 Macintosh，后来还有了 THINK C。我几乎每个暑假都沉浸在对游戏程序的破解中。自学是缓慢和充满困难的，我能够让一些简单的东西跑起来，但是随着程序规模的增加，让其运行起来越来越困难。
最开始的挑战仅仅是让部分程序工作起来。后来就变成了如何编写超过我大脑想象能力的程序 -- 我可以在想象中运行很多简单的程序，但是随着代码规模的增加，在脑海中运行完全变成了一件不可能的事情。我逐渐不再抱着《C++从入门到精通》，而开始寻找能够教会我如何组织代码的书籍。
几年过后，一个朋友给了我一本书：《设计模式：以可复用对象为目的的软件》。终于！我意识到，这就是我从十几岁以来的梦中情书。于是我一口气就把它读完了 -- 然后继续在我的程序中挣扎... 看到有那么多人面对和我同样的问题并找到了解决方案，实属欣慰。我真实地感到自己终于获得了一些趁手的工具。
2001年，我得到了梦寐以求的工作：Electronic Arts 软件工程师。彼时我迫不及待地想要看看真正的游戏程序是怎样被组装起来的，想要知道像 Madden Football 一样的大型游戏是如何架构的，游戏系统中每个部分是如何交互的，以及他们是怎么让同一个代码仓库运行在不同的平台上的。
探索源代码让我感到有点害羞，同时充满惊喜。每个游戏的代码里都有很多杰出的编码来实现如图形、AI、动画以及视觉效果等。我的同事们个个都是能够榨干处理器性能的行家，他们很可能在午饭前就已经完成了很多我都不知道“居然还可以这样”的事情。
同时我也发现，这些精彩的代码的架构方式一般都是在开发过后才进行整理的，也就是架构滞后于开发。开发者非常关注功能的实现，而代码的组织方式被严重忽略了。随处可见模块之间的耦合，开发新功能时，可能会对代码库中任何地方产生修改。说实话，这还让我挺反胃的，或许天下开发者大多都是这样，对设计模式一无所知。
当然啦，情况并没有非常糟糕(起码能跑是不是)。但是终结了我对游戏开发者“每天坐在满是白板的象牙塔里花几星期的时间冷静地讨论架构问题”的美好想象。事实上，我所面对的代码都是开发者们在紧张的排期压力下完成的，他们已经倾尽所能，并且我慢慢意识到，他们实际上做得非常出色，随着我接触代码库的时间慢慢变长，我发现的隐藏在混乱表面下的优秀代码也越来越多。
唯一不幸的一点就是 -- 他们被隐藏了。太多的开发者根本不知道代码仓库里有哪些好东西。我曾经就发现同事在努力地重新实现一个代码库中已经具备的功能。
这个问题就是这本书想要解决的。我将自己在游戏中发现的最好用的设计模式罗列出来，以此来帮助我们将时间用在创造新事物而不是重复造轮子上。
