我们在开始本示例之前，先整理出我们当前库中的代码类型。
- 工具方法:CommonUtil、GameObjectSimplify等。
- 类: MonoBehaviourSimplify。
静态方法中的方法全部都是工具方法，都是可以独立使用的，之所以可以独立使用，是因为这些工具方法所在类是没有状态的。
什么叫没有状态呢？ 比如 CommonUtil，其中的方法不管怎么使用，CommonUtil 类本身不会发生任何改变。但是像我们的 MonoBehaviourSimplify 用了一次 Show，那么它的 gameObject 成员就会发生改变，gameObject.active 值就会是 true，状态(数据)发生了改变。
CommonUtil 就是没有状态的，因为它只是静态方法的集合。
MonoBehaviourSimplify 是有状态的，不过仅仅是自身发生了状态的改变，所以这个类是独立的。而类中的方法 ShowHide 等并不是独立的。
我们得出了结论，CommonUtil 中的静态方法都是独立的。MonoBehaviourSimplify 类本身是独立的，其中的方法都不是独立的。
有了这个结论我们能做什么呢？
当然是去收集独立的类了。
我们的库从一开始收集自己的知识点，到能够收集静态独立方法而到现在，可以收集独立的类了。
所以从知识库升级到了静态方法库又升级到了类库。
当然并不是说到了类库就不能收集静态方法和知识了，知识和静态方法我们同样要收集。
那么我们要收集什么样的类呢？
当然是项目经常会用到的，或者是提高我们工作/编码效率的类呀，不只是类，任何这样的东西我们都要收集。类库只是暂时的，因为我们的认知目前就只能达到收集类库的水平，要想收集更复杂的东西，我们就要提升认知，不过在提升之前，我们先把类库掌握好。
既然要收集项目中经常会用到的或者提高我们工作/编码效率的类，那么我们就要思考。我们在项目中经常遇到的问题。
大多数开发者都要开发逻辑，不过说成开发逻辑还是太笼统了，我们再具体一点。把范围缩小的什么逻辑。UI 逻辑或者是数据存储逻辑、或者设计某个模块、某个系统、又或者是 GamePlay 逻辑等等。这些都是我们经常要写的逻辑。但是还是太过笼统，如果按照这个分类再分下去也没有太大的意义。
那么笔者呢，直接结合自己的经历讲了，笔者在最初做项目的时候，是把所有的代码都写到一个文件里或者写到一个类里，直到后来掌握了把一些可复用的代码提取成方法，提取了一段时间之后呢，自然就在准备写逻辑之前会去思考能不能直接设计成方法，再这样过了一段时间后，就考虑这些逻辑需不需要设计成方法，经过这一轮，对方法设计就掌握得很熟练了，之后再配合一些方法设计相关的书籍，使得自己写出来的方法可以做很多事情。
类也是一样的。不过类的设计范畴太大了，所以我们呢，就只思考独立的类，我们只需要继承它就能获得功能的这种类。
我们在最初做项目的时候，往往会遇到一个脚本访问的问题。比如挂在 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 获取第一时间更新通知及更多的免费内容。
