标签：master 答案 交流 并且 github 遇到 手册 ram src
我们在整理阶段解决了一些意外的问题。但是这些问题仅仅只是被解决而已，我们并没有去思考过这些问题是为什么产生的？以及在以后我们如何去避免这些问题的产生？
方法所在类的命名问题，最后我们通过方法分类解决了，并且学习了类的第一作用:方法的集合。
解决之后导致了大量的弃用代码，为了标记弃用代码，我们又简单学习了 System.Obselete 这个 API。
这样的意外问题真是好啊，可以让我们一下学习很多东西。不过如果在工作中或者做项目中全是意外问题，而身边又没人知道这么解决，那么每天肯定都会过得非常辛苦。
那么究竟是什么导致我们类的命名问题呢？
笔者的答案就是知识面少、知识量少、加上经验少。不过这个答案，只是一个设定而已。假定读者和笔者都不知道类的第一作用，并且是刚入门不久的 Unity 开发者，刚入门不久之后开发者肯定知识面少经验也少这是很正常的。所以按照这个设定走剧本的话，那么遇到这么多意外的问题就是很自然的事情。
知识面少，很容易理解，就是如果只会写 MenuItem，那么可以自己写出来示例一到示例七的代码。如果会好好运用访问权限，并且会设计方法，那么可以自己写出来示例八到示例十三的代码。如果知道类可以是方法的集合，那么就不会遇到这个方法所在类命名的问题了。
但是这个类可以是方法的集合这个观点，是笔者的观点，是直接在文章告诉大家的，是笔者产生的知识。虽然我们都知道类可以封装、继承、多态，并且还有静态类还能有访问权限甚至类可以进行拆分实现（partial），而且还可以用静态 this 扩展。但是对于方法所在类命名这个问题，我们只要知道类可以是方法的集合这个知识就可以解决了。当然在 C# 中结构体 (struct) 也可以是方法的集合。
到目前为止呢，我们积累了 13 个示例，而又通过这 13 个示例学习了很多知识，这些就是我们的知识量总和，很少了。
经验少，就是解决过的问题少，不过这是很正常的。按照设定，我们是第一次搭建库和框架，在这方面经验完全是零，所以说经验少也没有错。
不过没关系，这些呢都有应对策略的 ：
我们只要多解决一个类的命名问题，我们的知识面就广了一点，知识量就多了一点，经验就多了一点。
不过到此，还没有回答，如何避免”方法所在类命名“的这种问题。
要如何避免，这种问题遇到一次下次就知道如何解决了。那就多遇到这样的问题，这样在进行编码的时候就会有更多的设计工具来避免这样的问题。
当然也可以不用每次都遇到问题才去接触新的东西，可以先知道个大概的方向，根据这个方向去学习新的东西，在学习新的东西的时候去思考下能用在库的什么地方，用了是不是会更好？这样思考之后，在某一天遇到适用 的场景的时候，自然就会想到学到的东西了。
而学到的东西要记录下来，我们的知识库，有一个功能就是把新的知识点记录下来。
类似的问题，其实还有“产生了很多弃用的代码”等，这些是问题诞生的背后原因是和这个问题是一样的。
产生了很多弃用的代码，本质上是徒增了很多工作量。但是任何对代码的整理都离不开工作量的增加的，不过笔者认为这点工作量还是值得的。
通过问题分析，我们得到了一种全新的学习思路。以往我们是为了解决问题才去接触新的知识，新的 API，并把这个新的知识和 API 收录到我们示例里。而现在的思路呢，则是先学习新的东西，学习之后去思考，新的东西，能否用在我们的库中？用了是不是会让库变得更好？
而这是另一个学习思路。前者是被动接触新东西，是遇到了问题才去学习，后者是主动学习，学习之后再思考他的适用场景。两种各有优劣，前者的学习效率会比较高，就是会在最短的时间内学习最需要学的内容，缺点是一般会学得比较浅。后者是主动学习，学习之后知识不一定能够解决问题，但是呢，如果思考知识的适用场景，会让我们更深刻地理解知识。两者缺一不可。
以上这两点，就是今天这篇文章的核心。
今天的内容就这些，我们在下篇接着解决问题。
转载请注明地址：凉鞋的笔记：liangxiegame.com
QFramework 地址：https://github.com/liangxiegame/QFramework
QQ 交流群：623597263
Unity 进阶小班：
关注公众号：liangxiegame 获取第一时间更新通知及更多的免费内容。
Unity 游戏框架搭建 2019 (二十九) 方法所在类命名问题诞生的原因
标签：master 答案 交流 并且 github 遇到 手册 ram src
原文地址：https://www.cnblogs.com/liangxiegame/p/12684783.html
