Unity 游戏框架搭建 2019 (二十九) 方法所在类命名问题诞生的原因

我们在整理阶段解决了一些意外的问题。但是这些问题仅仅只是被解决而已，我们并没有去思考过这些问题是为什么产生的？以及在以后我们如何去避免这些问题的产生？

方法所在类的命名问题，最后我们通过方法分类解决了，并且学习了类的第一作用:方法的集合。

解决之后导致了大量的弃用代码，为了标记弃用代码，我们又简单学习了 System.Obselete 这个 API。

这样的意外问题真是好啊，可以让我们一下学习很多东西。不过如果在工作中或者做项目中全是意外问题，而身边又没人知道这么解决，那么每天肯定都会过得非常辛苦。

那么究竟是什么导致我们类的命名问题呢？

笔者的答案就是知识面少、知识量少、加上经验少。不过这个答案，只是一个设定而已。假定读者和笔者都不知道类的第一作用，并且是刚入门不久的 Unity 开发者，刚入门不久之后开发者肯定知识面少经验也少这是很正常的。所以按照这个设定走剧本的话，那么遇到这么多意外的问题就是很自然的事情。

知识面少

知识面少，很容易理解，就是如果只会写 MenuItem，那么可以自己写出来示例一到示例七的代码。如果会好好运用访问权限，并且会设计方法，那么可以自己写出来示例八到示例十三的代码。如果知道类可以是方法的集合，那么就不会遇到这个方法所在类命名的问题了。

但是这个类可以是方法的集合这个观点，是笔者的观点，是直接在文章告诉大家的，是笔者产生的知识。虽然我们都知道类可以封装、继承、多态，并且还有静态类还能有访问权限甚至类可以进行拆分实现（partial），而且还可以用静态 this 扩展。但是对于方法所在类命名这个问题，我们只要知道类可以是方法的集合这个知识就可以解决了。当然在 C# 中结构体 (struct) 也可以是方法的集合。

知识量少

到目前为止呢，我们积累了 13 个示例，而又通过这 13 个示例学习了很多知识，这些就是我们的知识量总和，很少了。

经验少

经验少，就是解决过的问题少，不过这是很正常的。按照设定，我们是第一次搭建库和框架，在这方面经验完全是零，所以说经验少也没有错。

不过没关系，这些呢都有应对策略的：

知识面少，主要是遇到的问题类型少，在本专栏的后续，会把笔者在搭建框架的过程中解决的所有能扩展知识面的问题都一个不落的进行分析解决。
知识量少，我们搭建知识库的目的，就是为了多增加知识量。
经验少，解决策略同 1.知识面少。

我们只要多解决一个类的命名问题，我们的知识面就广了一点，知识量就多了一点，经验就多了一点。

不过到此，还没有回答，如何避免”方法所在类命名“的这种问题。

要如何避免，这种问题遇到一次下次就知道如何解决了。那就多遇到这样的问题，这样在进行编码的时候就会有更多的设计工具来避免这样的问题。

当然也可以不用每次都遇到问题才去接触新的东西，可以先知道个大概的方向，根据这个方向去学习新的东西，在学习新的东西的时候去思考下能用在库的什么地方，用了是不是会更好？这样思考之后，在某一天遇到适用的场景的时候，自然就会想到学到的东西了。

而学到的东西要记录下来，我们的知识库，有一个功能就是把新的知识点记录下来。

类似的问题，其实还有“产生了很多弃用的代码”等，这些是问题诞生的背后原因是和这个问题是一样的。

产生了很多弃用的代码，本质上是徒增了很多工作量。但是任何对代码的整理都离不开工作量的增加的，不过笔者认为这点工作量还是值得的。

小结

通过问题分析，我们得到了一种全新的学习思路。以往我们是为了解决问题才去接触新的知识，新的 API，并把这个新的知识和 API 收录到我们示例里。而现在的思路呢，则是先学习新的东西，学习之后去思考，新的东西，能否用在我们的库中？用了是不是会让库变得更好？

而这是另一个学习思路。前者是被动接触新东西，是遇到了问题才去学习，后者是主动学习，学习之后再思考他的适用场景。两种各有优劣，前者的学习效率会比较高，就是会在最短的时间内学习最需要学的内容，缺点是一般会学得比较浅。后者是主动学习，学习之后知识不一定能够解决问题，但是呢，如果思考知识的适用场景，会让我们更深刻地理解知识。两者缺一不可。

以上这两点，就是今天这篇文章的核心。

根据问题去学习，并收集。
主动学习，并思考适用场景。

今天的内容就这些，我们在下篇接着解决问题。

转载请注明地址：凉鞋的笔记：liangxiegame.com