前言
今天发现之前写的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去加载指定的预制体,最后返回,这样就实现了新的需求,最后配置表也按照上述方式创建对应的一个配置表即可。
若以后有新的加载需求,则按接口规范新增即可,极大的扩展了灵活性和适应性。
网友评论