为什么要使用设计模式？

与他人一起工作

写代码时要保持这种心态：就好像将来要维护你这些代码的人是一位残暴的精神病患者，而且他知道你住在哪。（Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.） - Martin Golding

写程式并不是一件孤单的事。在开发的过程中，会有其他的同仁共同参与，你可能接手前人的程式，也可能会有人接手你现在撰写的程式；程式不只是一批只交付给机器执行的命令，也是一种读物，你阅读别人的程式，别人也会阅读你的程式，因为程式就是写作与阅读，所以程式本身就是沟通。

你想要读懂别人的程式，也想要让别人可以读懂你的程式，那么在工程师之间就需要一套共同的词汇与修辞学。

如果我们把变数想像成单字、把程式语言的语法想成文法，那么我们知道，有时候一篇文章就算你每个字都看得懂，但是把每个字串在一起，你就是不知道里头到底想要表达什么，所以你就会需要一套把不同元素组合在一起的叙事结构，像是起承转合、像是倒叙法…在实例导向程式中，这种排列方式就是设计模式。

学习设计模式就是学习工程师的语言，使用设计模式就是与其他工程师沟通，让其他参与人可以快速理解整个软体的架构。

适应软件的变化

如果我们把设计模式理解成物件的排列方式，我们透过一套有系统的方式，把物件组织起来，也就是管理物件之间的关系。而管理物件的关系，除了代表让一些物件有关系之外，同时也代表让许多物件之间没有关系，解除实例之间的相依性。

如果在一个有了一些年纪的code base 上工作，你会发现，所谓维护一套软件，其实就是在不断改动软件，你不但要让基本功能随着时间过去、作业系统与SDK 的改版还能够继续运作，还要随着每年的商业目标改变而满足不同的需求，有些新的需求会诞生，有些过去的需求会不复存在，你会不断增加新的功能，另一方面，你也会需要不断移除没有用的程式码。

从软体中移除程式码远比加入程式码困难，如果我们加入程式码的时候就像把一把红豆洒进一缸绿豆，那么删除程式码就像是要从一缸绿豆里头把这一把红豆一颗一颗挑出来。如果一开始每个实例之间的关系都纠结在一起，当我们想要移除没有用到的程式时，根本就无从下手，而放任无用的程式继续在软件中存活，最终就会危害整体的软件品质。

维护软件就是改动软件，撰写单元测试是为了有工具可以让我们在改动的时候，确认没有把软件改烂，使用设计模式则是让我们想要改动的时候还有办法改得动。维护一套有一些年纪的软体，在每次把程式加进去的时候，都要考虑以后你要怎么把这些程式拿出来。