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

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

工具方法: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 (四十五) 独立的方法和独立的类相关推荐

Unity 游戏框架搭建 2019 (四十二) MonoBehaviour 简化
在前两篇,我们完成了第九个示例.为了完善第九个示例,我们复习了类的继承,又学习了泛型和 params 关键字. 我们已经接触了类的继承了.接触继承之前,把类仅仅当做是方法的集合,接触了继承之后,我们的 ...
class unity 定义类_Unity 游戏框架搭建 2019 (二十五) 类的第一个作用与 Obselete 属性...
在上一篇我们整理到了第七个示例,我们今天再接着往下整理.我们来看第八个示例: #if UNITY_EDITORusing UnityEditor; #endif using UnityEngine; ...
Unity 游戏框架搭建 2019 (四十七) 集成到 MonoBehaviourSimplify
还记得我们的简易消息机制是为了解决什么问题诞生的嘛? 是为了解决脚本间访问的问题. 我们回过头再看下 A 脚本如果想访问 B 脚本,使用消息机制,如何实现. 代码如下: public class A ...
Unity 游戏框架搭建 2018 (四) 我所理解的框架
前言架构和框架这些概念听起来很遥远,让很多初学者不明觉厉.会产生"等自己技术牛逼了再去做架构或者搭建框架"这样的想法.在这里笔者可以很肯定地告诉大家,初学者是完全可以去做这些事情 ...
Unity 游戏框架搭建 (九) 减少加班利器-QConsole
为毛要实现这个工具? 在我小时候,每当游戏在真机运行时,我们看到的日志是这样的. 没高亮啊,还有乱七八糟的堆栈信息,好干扰日志查看,好影响心情. 还有就是必须始终连着usb线啊,我想要想躺着测试... ...
Unity 游戏框架搭建 (七) 减少加班利器-QApp类
本来这周想介绍一些框架中自认为比较好用的小工具的,但是发现很多小工具都依赖一个类----App. App类的职责: 1.接收Unity的生命周期事件. 2.做为游戏的入口. 3.一些框架级别的组件初始 ...
Unity 游戏框架搭建 (五) 简易消息机制
什么是消息机制? 23333333,让我先笑一会. 为什么用消息机制? 三个字,解!!!!耦!!!!合!!!!. 我的框架中的消息机制用例: 1.接收者 using UnityEngine;names ...
Unity 游戏框架搭建 (二十一) 使用对象池时的一些细节
上篇文章使用SafeObjectPool实现了一个简单的Msg类.代码如下: class Msg : IPoolAble,IPoolType{#region IPoolAble 实现public vo ...
Unity 游戏框架搭建 2018 (一) 架构、框架与 QFramework 简介
约定还记得上版本的第二十四篇的约定嘛?现在出来履行啦~ 为什么要重制? 之前写的专栏都是按照心情写的,在最初的时候笔者什么都不懂,而且文章的发布是按照很随性的一个顺序.结果就是说,大家都看完了,都还 ...

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

更多内容

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

最新文章

热门文章