一个优秀的Unity3d开发者必备的几种设计模式

众所周知，unity的编程属于脚本化，脚本没有一个具体的概念跟架构， 导致在项目过程中，经常出现哪里需要实现什么功能，就随便添加脚本，
结果，就造成了一片混乱，不好管理。

更有甚者，自己的写的代码闲置一段时间后，再去想找某个功能的实现，都要在视图中翻来覆去找半天。
哎!请容许我在此感叹一声，这还是你写的东西么？
因此，一个好的设计模式是多么的重要啊，

如何写脚本架构
那么，我们在使用unity3d开发东西的时候，脚本架构到底应该如何来写？
其实，我也给不了你们具体答案，因为每个人的开发习惯，每个团队的开发模式也各有千秋，
so，在此我只做几种设计模式的总结，

设计模式对编程人员来说，的确非常重要。
当然，如果大家的理解跟我有所不同，欢迎留言，大家共同探讨。

单一职责原则
说到单一职责原则，很多人都会不屑一顾。
因为它太简单了，稍有经验的程序员即使从来没有读过设计模式、从来没有听说过单一职责原则，在设计软件时也会自觉的遵守这一重要原则，因为这是常识。
在软件编程中，谁也不希望因为修改了一个功能导致其他的功能发生故障。
而避免出现这一问题的方法便是遵循单一职责原则。
虽然单一职责原则如此简单，并且被认为是常识，但是即便是经验丰富的程序员写出的程序，也会有违背这一原则的代码存在。
为什么会出现这种现象呢？因为有职责扩散。所谓职责扩散，就是因为某种原因，职责被分化成了更细的职责。

用一个类描述动物呼吸这个场景

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，代码如下：

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();

terrestrial.breathe("牛");

terrestrial.breathe("羊");

terrestrial.breathe("猪");

Aquatic aquatic = new Aquatic();

aquatic.breathe("鱼");

}

}

//运行结果：

//牛呼吸空气

//羊呼吸空气

//猪呼吸空气

//鱼呼吸水

改动量小的方法
我们会发现如果这样修改花销是很大的，除了将原来的类分解之外，还需要修改客户端。
而直接修改类Animal来达成目的虽然违背了单一职责原则，但花销却小的多，代码如下：

class Animal

{

public void breathe(String animal)

{

if ("鱼" == animal)

{

Debug.Log((animal + "呼吸水"));

}

else

{

Debug.Log((animal + "呼吸空气"));

}

}

}

public class Client

{

public static void main(String[] args)

{

Animal animal = new Animal();

animal.breathe("牛");

animal.breathe("羊");

animal.breathe("猪");

animal.breathe("鱼");

}

}

隐患
可以看到，这种修改方式要简单的多。
但是却存在着隐患：有一天需要将鱼分为呼吸淡水的鱼和呼吸海水的鱼，
则又需要修改Animal类的breathe方法，而对原有代码的修改会对调用“猪”“牛”“羊”等相关功能带来风险，
也许某一天你会发现程序运行的结果变为“牛呼吸水”了。
这种修改方式直接在代码级别上违背了单一职责原则，虽然修改起来最简单，但隐患却是最大的。

另一种修改方式

class Animal

{

public void breathe(String animal)

{

Debug.Log(animal + "呼吸空气");

}

public void breathe2(String animal)

{

Debug.Log(animal + "呼吸水");

}

}

public class Client

{

public static void main(String[] args)

{

Animal animal = new Animal();

animal.breathe("牛");

animal.breathe("羊");

animal.breathe("猪");

animal.breathe2("鱼");

}

}

可以看到，这种修改方式没有改动原来的方法，而是在类中新加了一个方法，这样虽然也违背了单一职责原则，
但在方法级别上却是符合单一职责原则的，因为它并没有动原来方法的代码。这三种方式各有优缺点，
那么在实际编程中，采用哪一中呢？
其实这真的比较难说，需要根据实际情况来确定。
我的原则是：只有逻辑足够简单，才可以在代码级别上违反单一职责原则；只有类中方法数量足够少，才可以在方法级别上违反单一职责原则。

更多unity2018的功能介绍请到paws3d爪爪学院查找。