在之前，我们编写的模板类文件时，总有个子类继承模板类，来重解析父类的字符串配置奖励...
当项目功能越做越多时，这种很恶心的解析一次又一次的复制很是讨厌，多人之间写法又不完全一致，导致后期维护很头大...
来看一下Noark提供的转化器带来的新感受
比如副本通关奖励配置格式如下
道具编号:数量,道具编号:数量,道具编号:数量
编码SimpleItem.java
1public class SimpleItem { 2 private String id; 3 private int num; 4 //省略GetSet方法... 5}
编码SimpleItemList.java
1public class SimpleItemList { 2 private List<SimpleItem> items; 3 //省略GetSet方法... 4}
副本模板类添加SimpleItemList注入
1@TplAttr(name = "Items") 2private SimpleItemList items;
是不是很像模板注入中的IntList，没错就是这样简单方便，但是这还不能正常工作...
每一个成功运作的背后都有一个类型转化器在默默的为他解析构建生成注入...
编写SimpleItemListConverter.java
1@TemplateConverter(SimpleItemList.class) 2public class SimpleItemListConverter extends AbstractConverter<SimpleItemList> { 3 4 @Override 5 public SimpleItemList convert(String value) throws Exception { 6 SimpleItemList result = new SimpleItemList(); 7 if (StringUtils.isNotEmpty(value)) { 8 String[] items = StringUtils.split(value, ","); 9 List<SimpleItem> itemList = new ArrayList<>(items.length); 10 for (String item : items) { 11 String[] args = StringUtils.split(item, ":"); 12 itemList.add(new SimpleItem(args[0], Integer.parseInt(args[1]))); 13 } 14 result.setItems(itemList); 15 } else { 16 result.setItems(Collections.emptyList()); 17 } 18 return result; 19 } 20 21 @Override 22 public String buildErrorMsg() { 23 return "道具编号:数量,道具编号:数量,道具编号:数量"; 24 } 25}
需求又来了，如果策划说副本扫荡奖励也跟这个长一样，是不是还要写个类再写个转化器呢？
如果是配置格式长得一样，那就直接用嘛
1@TplAttr(name = "SweepReward") 2private SimpleItemList sweepReward;
只要编写一次，到处转化...
研发中，有了转化器的存在，整体性福感满满的，因为再也不会有相同功能的配置长两种格式，数值大爷都爱你了...
想当年啊，策划A设计通关奖励是用逗号，策划B在扫荡奖励用分号，程序观点反正坑得是数值，数值观点反正出了问题找程序，一直在相互伤害中成长