将仓库克隆到D:\Pattern目录下，否则图片将看不到

我们知道所有软件都是需要维护的。但是有的软件维护起来很舒服，有的却分分钟让人抓狂。这是为什么呢？因为代码的组织方式、软件架构是有好坏的。这些方面做好了，你的系统条理十分清晰、能够很容易的应对需求的改变。所以我们学习软件开发不能只是说“哦，我做出了什么什么软件，我实现了什么什么功能”，我们还要追求我们的代码是否扩展性优良、容错性优良、维护友好。

《大话设计模式》程杰：这本书能够由浅入深的带我们认识每一个设计模式。 《游戏编程模式》Robert Nystorm：这本书将设计模式运用到游戏的思考中，可以给我们游戏程序员更好的掌握设计模式。

接下来，我们来简单看一下《游戏编程模式》中对软件架构的讨论。

好的设计当程序员做出改动时，可以调用少量的可选函数来完美解决一个问题，而不会给整体程序带来副作用。

如果两块代码耦合，意味着你必须同时了解这两块代码。如果你让他们解耦，那么你只需要了解其一。这是软件架构的一个关键目标。 当然，解耦的另一个定义是：当修改了一块代码时不必再修改另一块代码。尽量介绍修改波及的范围。

这似乎正是人们会对抽象、模块化、设计模式和软件架构兴奋的原因。良好的软件架构在生产力上会形成巨大的差异。怎么夸它带来都不为过。

但是，天下没有免费的午餐。良好的架构需要一系列准则和努力。每当你实现一个功能时，你必须优雅的将它们融入到整个系统中。所以，你必须如履薄冰地组织代码并保证它在开发周期中经历数以千计的修改后仍具有良好的组织性。

你必须考虑程序那一部分应该要解耦然后再这些地方引入抽象。同样的，你要确定在哪里做一些扩展以便将来很容易应对变化。 如此种种，都将延长你组织代码的时间。 另外，许多模式在增加你代码的灵活性时蚕食你的性能。

因此，设计模式不是说用的越多越好，而是在你可预见的前提下，利大于弊的分析下才使用。而这种经验之谈只有多与大牛交流或者时间积累才能学习到。

为了让设计模式更加的贴近生活，易于理解，md文件中在讲解各模式的时候，包含有Pattern工厂的故事。