前言
今天发现之前写的Config配置表不适应当前的项目了，配置表装了一堆消息，并且消息的格式是固定的
现在问题来了，因为消息的格式是固定的，如果我要获取a对象并且实例化到场景中，之前的流程是通过config配置表找到指定的数据，在拿到其中的a预制体
最后在创建a预制体到场景中，由于config是继承了ScriptTable，因此这些预制体事先是直接拖上去的，这就导致配置表配置信息出现了局限性。
新的需求
现在新的需求是要让配置表不直接配置预制体，而是配置预制体的路径，在需要用的时候再去加载预制体本身给上层使用。
很显然，之前的模式不可能适应这种方式。那么用传统方法该怎么写？重写新的一套预制体配置模式吗？
如果仅仅实现需求当然可以重写一套新的，但是如果以后还有其他新的方式呢？
比如配置表配置预制体名称，需要用的时候在去asset bundle中加载，这又需要写一套新的，这样在工作量和代码维护上都显得吃力。
Interface登场！！！
先理一下之前的流程：
Manager需要配置表（config）提供查找指定table的数据（info），然后从数据中拿到指定的预制体数据（prefab）
在没有接口之前我会创建三个对象，分别是：manager、config、info
很显然现在完全不能满足今天的需求了。
那用接口的思路应该怎么理解？
首先Manager工具类是固定的，因此可以确定Manager不变，最后我想将配置数据那一块改为可扩展，多样化，知道这些信息后思路如下：
- Manager需要一个查询指定table的工具
- Manager在需要的时候会从table对应对象中拿到一个预制体
以上是核心功能，
创建一个Iinfo接口，并且接口中会声明一个GetPrefab方法，该方法返回一个预制体对象
然后创建一个IConfig类，并声明一个GetInfowithTabel接口，他会返回一个IInfo对象
最后将Manager的初始化函数改为传入一个IConfig接口对象，这样就大功告成。
现在我有了Manager、IConfig、IInfo了，我可以在保留之前的配置表模式下，新增一套配置表模式。
如下：
我新建一个NormalInfo对象并实现了IInfo，他里面有一个A变量，方便增加把预制体拖到变量上去，
同时在新建一个NormalConfig对象，实现IConfig接口，他有一个List<NormalInfo>的list，最后继承ScriptTable，方便生成.asset文件，然后后之前代码一样直接在面板上配置数据。
新的Resource模式则创建一个ResInfo，它有一个APath变量，通过配置表配置预制体地址，然后实现IInfo接口，在GetPrefab中通过APath去加载指定的预制体，最后返回，这样就实现了新的需求，最后配置表也按照上述方式创建对应的一个配置表即可。
若以后有新的加载需求，则按接口规范新增即可，极大的扩展了灵活性和适应性。
