好的程序员必备的6种设计模式..docVIP

本帖最后由 ζ?随风去旅行 于 2014-8-31 18:43 编辑 unity编程众所周知，它是属于脚本化，脚本没有一个具体的概念跟架构， 导致在项目过程中，经常出现哪里需要实现什么功能，就随便添加脚本， 结果，就造成了一片混乱，不好管理。 更有甚者，自己的写的代码闲置一段时间后，再去想找某个功能的实现，都要在视图中翻来覆去找半天。 哎!请容许我在此感叹一声，这还是你写的东西么？ 因此，一个好的设计模式是多么的重要啊， 那么，我们在使用unity3d开发东西的时候，脚本架构到底应该如何来写？ 呵呵... 其实，我也给不了你们具体答案，因为每个人的开发习惯，每个团队的开发模式也各有千秋， so，在此我只做几种设计模式的总结， 主要参考书籍有《设计模式》《设计模式之禅》《大话设计模式》以及网上一些零散的文章， 但主要内容还是我本人的一些经验以及感悟。 写出来的目的一方面是系统地整理一下，一方面也与广大的网友分享， 至于你们到底如何使用， 望君斟酌啊! 因为设计模式对编程人员来说，的确非常重要。 当然，如果大家的理解跟我有所不同，欢迎留言，大家共同探讨。 设计模式六大原则（1）：单一职责原则 说到单一职责原则，很多人都会不屑一顾。 因为它太简单了，稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。 在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。 而避免出现这一问题的方法便是遵循单一职责原则。 虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。 为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责被分化成了更细的职责。 如：用一个类描述动物呼吸这个场景。 [C#] 纯文本查看 复制代码 class Animal{ public void breathe(string animal) { Debug.Log(animal+呼吸空气); }}public class Client{ Animal animal = new Animal(); void Start() { animal.breathe(牛); animal.breathe(羊); animal.breathe(猪); }} 运行结果：牛呼吸空气羊呼吸空气猪呼吸空气程序上线后，发现问题了，并不是所有的动物都呼吸空气的，比如鱼就是呼吸水的。修改时如果遵循单一职责原则，需要将Animal类细分为陆生动物类Terrestrial，水生动物Aquatic，代码如下：[C#] 纯文本查看 复制代码 class Terrestrial { public void breathe(String animal){ Debug.Log(animal + 呼吸空气); } } class Aquatic { public void breathe(String animal){ Debug.Log(animal + 呼吸水); } } public class Client { public static void main(String[] args) { Terrestrial terrestrial = new Terrestrial(); Debug.Log(terrestrial.breathe(牛)); Debug.Log(terrestrial.breathe(羊)); Debug.Log(terrestrial.breathe(猪)); Aquatic aquatic = new Aquatic(); Debug.Log( aquatic.breathe(鱼)); } } 运行结果：牛呼吸空气羊呼吸空气猪呼吸空气鱼呼吸水我们会发现如果这样修改花销是很大的，除了将原来的类分解之外，还需要修改客户端。而直接修改类Animal来达成目的虽然违背了单一职责原则，但花销却小的多，代