一个优秀的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爪爪学院查找。链接https://www.paws3d.com/learn/，也可以加入unity学习讨论群935714213
近期更有资深开发人士直播分享unity开发经验，详情请进入官网或加入QQ群了解