初衷
学游戏制作也有一段时间了，越来越觉得游戏制作对于我们程序员来说根本还是在编程而不是使用引擎(或许是unity太好用了，让我忽略了这个最浅显的道理)。之前也一直在依赖引擎，但是随着深入才发现本末倒置了。所以，今天开始持续更新设计模式文集。并且，今后的主要任务就是加强编程能力。
我们知道所有软件都是需要维护的，游戏也一样。但是有的软件维护起来很舒服，有的却分分钟让人抓狂。这是为什么呢？因为代码的组织方式、软件架构是有好坏的。这些方面做好了，你的系统条理十分清晰、能够很容易的应对需求的改变。所以我们学习软件开发不能只是说“哦，我做出了什么什么软件，我实现了什么什么功能”，我们还要追求我们的代码是否扩展性优良、容错性优良、维护友好。
本文集参考的书籍
《大话设计模式》程杰：这本书能够由浅入深的带我们认识每一个设计模式。
《游戏编程模式》Robert Nystorm：这本书将设计模式运用到游戏的思考中，可以给我们游戏程序员更好的掌握设计模式。
案例
本文集中出现的案例我都会放到github上供大家参考。
接下来，我们来简单看一下《游戏编程模式》中对软件架构的讨论。
什么是好的软件架构
好的设计当程序员做出改动时，可以调用少量的可选函数来完美解决一个问题，而不会给整体程序带来副作用。
我们如何从解耦中获益
如果两块代码耦合，意味着你必须同时了解这两块代码。如果你让他们解耦，那么你只需要了解其一。这是软件架构的一个关键目标。
当然，解耦的另一个定义是：当修改了一块代码时不必再修改另一块代码。尽量介绍修改波及的范围。
代价
这似乎正是人们会对抽象、模块化、设计模式和软件架构兴奋的原因。良好的软件架构在生产力上会形成巨大的差异。怎么夸它带来都不为过。
但是，天下没有免费的午餐。良好的架构需要一系列准则和努力。每当你实现一个功能时，你必须优雅的将它们融入到整个系统中。所以，你必须如履薄冰地组织代码并保证它在开发周期中经历数以千计的修改后仍具有良好的组织性。
你必须考虑程序那一部分应该要解耦然后再这些地方引入抽象。同样的，你要确定在哪里做一些扩展以便将来很容易应对变化。
如此种种，都将延长你组织代码的时间。
另外，许多模式在增加你代码的灵活性时蚕食你的性能。
因此，设计模式不是说用的越多越好，而是在你可预见的前提下，利大于弊的分析下才使用。而这种经验之谈只有多与大牛交流或者时间积累才能学习到。
网友评论