到目前为止，我们的库作为知识收录这个功能来说，已经非常好用了，由于使用了 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 逻辑等等。这些都是我们经常要写的逻辑。但是还是太过笼统，如果按照这个分类再分下去也没有太大的意义。