Unity 游戏框架搭建 2019 (四十四、四十五) 关于知识库的小结&独立的方法和独立的类

在上一篇，我们完成了一个定时功能，并且接触了 Action 和委托、lambda 表达式这些概念。

到目前为止，我们的库作为知识收录这个功能来说，已经非常好用了，由于使用了 partial 关键字，所以重复的代码少了很多。而作为一个可复用的工具库来说，勉强能够应付。

通过 partial 关键字，理论上可以对已有了类，进行无限地增加示例。而我们的示例的类型呢，主要是写可独立使用的方法和 MenuItem 示例。什么叫独立使用的方法？到目前为止我们写的所有静态方法都是可以独立使用的，这些方法并不需要与其他方法或对象进行协作就可以发挥本身的价值。

什么样的方法不能独立使用呢？这种非常常见，比如资源的加载和卸载 Load/UnLoad, UI 的打开和关闭，事件的发送/接收/注册，这种方法都不能独立使用，而是需要和其他的方法配合使用。这种类型的方法往往都定义在一个类里，是需要进行更严格地设计的。不像我们目前写的这几个 partial 类中的方法，再增加一个方法很少要考虑之前在类中已实现的方法，我们只要保证逻辑不重复就可以了。

而在设计不可独立使用的方法呢，要保证逻辑不能重复的同时，要更多地考虑互相如何更好地协作，从方法结构、调用顺序、命名、访问权限、所在类这些都要进行严格地设计，才会得到一个合格的方法。

对开发者的要求会高很多。

我们在上一篇的定时功能，就有点这个苗头，我们的定时方法的权限是 public 类型的，由于实现需要用到 Coroutine 所以又定义了一个实现方法，用来实现 Coroutine 逻辑，而这个 Coroutine 逻辑不希望被子类和外部类访问到，所以访问权限就设置成了 private，这样才算是一个合格的方法。

而这个方法仅仅和合格而已，其实用笔者角度来看，问题非常多，比如要考虑 Coroutine 中断问题，也要考虑 MonoBehaviourSimplify 这个类的使用问题，这个类现在可以直接挂到 GameObject 上，而笔者不希望用户这样去使用 MonoBehaviourSimpleify，而是通过继承使用，要解决的话其实也很简单，使用抽象类就好了。但是这样一来，我们的上一篇文章的信息量就会很多，并且在上一篇我们是刚刚接触继承这个概念，如果一篇文章就把继承从入门到掌握再到精通都讲完，那大家吸收的效果就会差很多。所以我们还是慢慢来，罗马不是一天建成的。

总之，目前，对于读者来说，自己写一个示例或者收集笔者的示例，是没啥太大的问题了。毕竟我们已经实践了很多了。从笔者的角度来说，专栏的约定和规则已经稳定了。

从下一个示例开始呢，我们开始进行库的专项训练。

我们在开始本示例之前，先整理出我们当前库中的代码类型。

工具方法: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

凉鞋的笔记

Unity 游戏框架搭建 2019 (四十四、四十五) 关于知识库的小结&独立的方法和独立的类

更多内容