最近写了一个功能就是通过传入不同的rule实现不同的规则，这里rule是个字符串，按照常理来说，我们最先想到的是switch case,但Switch case有个问题就是代码耦合度会特别高，想起武哥之前说的一段话：写代码时不时就要review一下，写第一个方法可以大概写，第二个方法就得想想和上一个可不可以重用，能重用多少，再多几个方法的时候就得思考可不可以用工厂来实现，于是，这一次再武哥又一次的提醒下，发现了这里的代码可以重用，那么一个工厂类怎么写才能叫一个好的工厂类呢？那当然就是反射接口的工厂类了，依据反射，通过名字拿到具体的类。
结构
从结构上来看，如果是完成解决同一类问题的不同方法，首先想到的就是接口，通过接口可以轻松解耦代码，例如，假设我这里需要解决喝开门的问题，就可以有用手推开，用脚踢开等多个方法，方法的名称可以一样，在接口里定义，但方法的实现各自不同。对于我目前的问题就是：我要校验数据，而对于不同的数据需要使用不同的校验方法，结构上来看就是一个接口形式（当然你可以用switch case，但会使代码看上去很冗余，而且耦合度很高，不可扩展）
其中IJsonCompareRule就是这里的接口方法，而CompareFactory就是我们这里定义的反射接口工厂，反射接口工厂的作用就是仅仅通过规则的名称就可以把规则类拿到。下面看详细操作
定义
IJsonCompareRule代码清单：
internal interface IJsonCompareRule { //用来比较的接口方法 bool JsonCompare(JsonCompareModel jsonCompareModel, ref StringBuilder failureMessage, ref int count); }
CompareFactory代码清单：
namespace TML { internal class ConverterFactory : FactoryBase<ConverterFactory, IJsonCompareRule>, IFactory<IJsonCompareRule> //IJsonCompareRule为接口 { public IJsonCompareRule NewObject(string 类名称) { var result = CloudApp.Common.ReflectionHelper.CreateInstance<IJsonCompareRule>("程序集名称", "命名空间地址." + 类名称); if (result == null) { throw new ConfigException($"{className}反射失败"); } return result; } } }
使用
通过以上定义，在使用的时候就可以避免各种switch case，耦合度轻松降低
ConverterFactory.Instance.NewObject(rule + "Rule").JsonCompare(jsonCompareModel, ref failureMessage, ref count);
核心思想：解耦，不停的想着review，It’s very important。
另外闲扯两句，今天听了运维的技术分享，感觉很棒啊，DevOps，自动化，透明运维，开发与运维的边界，应用运维的概念提的都非常棒，多了解些别人的工作领域，对于合作和成长之类的比较有用吧
