【C#編程最佳實踐 十七】反射工廠最佳實踐

最近寫了一個功能就是通過傳入不同的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，自動化，透明運維，開發與運維的邊界，應用運維的概念提的都非常棒，多瞭解些別人的工作領域，對於合作和成長之類的比較有用吧