那么笔者呢，直接结合自己的经历讲了，笔者在最初做项目的时候，是把所有的代码都写到一个文件里或者写到一个类里，直到后来掌握了把一些可复用的代码提取成方法，提取了一段时间之后呢，自然就在准备写逻辑之前会去思考能不能直接设计成方法，再这样过了一段时间后，就考虑这些逻辑需不需要设计成方法，经过这一轮，对方法设计就掌握得很熟练了，之后再配合一些方法设计相关的书籍，使得自己写出来的方法可以做很多事情。
类也是一样的。不过类的设计范畴太大了，所以我们呢，就只思考独立的类，我们只需要继承它就能获得功能的这种类。
我们在最初做项目的时候，往往会遇到一个脚本访问的问题。比如挂在 A GameObject 的 A 脚本，如果想访问 B GameObject 的 B 脚本。笔者当时使用方式呢，当然是使用连线的方式。在 A 脚本中声明一个 public B b; 然后在 A 脚本的 Inspector 上就可以对这个变量进行赋值，这样在最开始写逻辑的时候真的很方便很好用，不过过了不久，用了一段时间后就发现会变得非常乱。直到连功能都不能加了为止，笔者都没有意识到是这个问题。
A 脚本的代码如下:
public class A : MonoBehaviour { public B b; void Start() { b.DoSomething(); } }而 Unity 的这个特性，让很多新手觉得 Unity 好强大，这些新手就有笔者一个。后来才知道，这样做是一个坑。
那么 A 访问 B 脚本这样的逻辑，在项目开发时候是使用得最多的。那么除了连线有没有更好的方案呢？当然有的。
笔者在之后呢很快接触了单例模式。发现只要把每个脚本都写成单例，那么所有的脚本，都可以随便访问了，真的爽翻了，而且比连线好用了好多，使用连线的时候，public 成员变量都不知道拿来干嘛的，而使用单例，最起码可以使用 IDE 的可以跟踪到代码定义的地方。
代码如下:
public class A : MonoBehaivour { public static A Instance; void Awake() { Instance = this; } void Start() { B.Instance.DoSomething(); } void OnDestroy() { Instance = null; } } public class B : MonoBehaivour { public static B Instance; void Awake() { Instance = this; } void DoSomething() { // do something } void OnDestroy() { Instance = null; } }这种单例模式，在 Unity 中最容易实现的单例。而笔者见过身边工作了 4 ~ 5 年工作经验的同事也在用这种单例，不过作为过来人，要提醒各位，这种单例要谨慎使用，后边呢有更合理的方式。
就这样，笔者当时就用这样的单例写了好几个项目，并且心里觉得，天呐终于接触设计模式了。设计模式真好用，真想全部学了。。。
不管怎么样，如何解决脚本之间互相访问这个问题，是一个很大的问题。而使用单例其实是作为没有主程带的初学者都必须经历的一个阶段，所以没有必要去喷初学者的代码，大家都是这样过来的。
已经跟专栏跟到这里的童鞋，已经是非常可贵的了。
今天的内容就这些，我们下一篇再见，我们今天没有示例，所以不用导出。
转载请注明地址：凉鞋的笔记：liangxiegame.com
更多内容
QFramework 地址：https://github.com/liangxiegame/QFramework
QQ 交流群：623597263
Unity 进阶小班：
主要训练内容：
跟着案例学 Shader（第一年）
副业的孵化（第二年、第三年）
权益、授课形式等具体详情请查看《小班产品手册》：https://liangxiegame.com/master/intro
关注公众号：liangxiegame 获取第一时间更新通知及更多的免费内容。
