Unity 游戏框架搭建 2019 (四十五) 独立的方法和独立的类

最新推荐文章于 2024-09-26 18:09:56 发布

凉鞋的笔记

最新推荐文章于 2024-09-26 18:09:56 发布

阅读量2.3k

点赞数 12

分类专栏： Unity 游戏框架搭建 Unity Unity游戏框架搭文章标签： c# unity 游戏框架

本文链接：https://blog.csdn.net/yukikit/article/details/106031673

版权

Unity 同时被 3 个专栏收录

68 篇文章 15 订阅

订阅专栏

Unity游戏框架搭

59 篇文章 12 订阅

订阅专栏

Unity 游戏框架搭建

52 篇文章 64 订阅

订阅专栏

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

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