使用反射+策略模式代替項目中大量的switch case判斷

我這里的業務場景是根據消息類型將離線消息存入mongoDB不同的collection中。其中就涉及到大量的分支判斷，為了增強代碼的可讀性和可維護性，對之前的代碼進行了重構。

先對比一下使用反射+策略模式前后的代碼：

重構前：

重構后：

我們可以看到重構前的代碼充斥着大量的分支判斷，以后每增加一個新的消息類型就要增加一個新的具體實現類和增加一個新的分支判斷，可拓展性是相當差的；而重構后的代碼當需要增加一個新的消息類型時，只需要增加一個具體的實現類就可以實現，根本不需要考慮分支判斷，這也是我們希望看到的。

接下來我們看一下具體的實現過程：

1.抽象策略類

定義了具體策略類需要執行的具體操作，並且對外部提供了一個觸發操作的方法。抽象策略類中還定義了兩個屬性LogSource和Operation，這樣mongoDB中的Collection名和消息枚舉類型Operation就形成一對一的關系。注意我們把這兩個屬性的set權限定義為protected ，屬性賦值操作在具體策略類實現。實現了不同的消息類型對應不同的具體策略類對應不同的mongo Collection。

public abstract class SaveOffLineMessageTemplate<T>
    {
        /// <summary>
        /// 日志源和mongo表名
        /// </summary>
        public string LogSource { get; protected set; }
        /// <summary>
        /// 操作類型
        /// </summary>
        public Operation Operation { get; protected set; }

        /// <summary>
        /// 保存消息到mongoDB
        /// </summary>
        /// <param name="message">消息</param>
        /// <param name="userRole">接收用戶角色</param>
        /// <param name="messageSendTag">是否發送標志 0未發送 1已發送</param>
        /// <returns></returns>
        public async Task<bool> AddMessageToMongo(string message, UserRoleEnum userRole, int messageSendTag)
        {
            //消息反序列化
            var model = DeserializeObject(message);
            //獲取用戶設備集合
            var devices = QueryUserDevice(model);
            //組裝數據
            var combineData = CombineData(model, devices, userRole);
            //記錄日志
            Log.MyLog.Info(LogSource + "AddMessageToMongo", "保存消息到mongoDB", JsonConvert.SerializeObject(model) + JsonConvert.SerializeObject(devices));
            //保存到mongoDB
            return await MessageDB.AddOffLineMessage(combineData, LogSource);
        }
        /// <summary>
        /// 消息反序列化
        /// </summary>
        /// <typeparam name="T">模板類</typeparam>
        /// <param name="message">消息</param>
        /// <returns></returns>
        public abstract T DeserializeObject(string message);

        /// <summary>
        /// 獲取用戶設備集合
        /// </summary>
        /// <returns></returns>
        public abstract List<DevicesMongoModel> QueryUserDevice(T model);

        /// <summary>
        /// 組裝數據
        /// </summary>
        /// <returns></returns>
        public abstract MessageMongoModel CombineData(T model, List<DevicesMongoModel> devices, UserRoleEnum userRole, int messageSendTag);
    }

2.具體策略類

實現了抽象策略類定義的操作。在此處給抽象策略類的消息操作類型Operation和LogSource進行賦值。

 public class SaveLoginPasswordModify : SaveOffLineMessageTemplate<FinanceBase>
    {
        public SaveLoginPasswordModify() : base()
        {
            this.Operation = Operation.登陸密碼變更消息推送;
            this.LogSource = "Retail";
        }

        public override FinanceBase DeserializeObject(string message)
        {
            FinanceBase model = JsonConvert.DeserializeObject<FinanceBase>(message);
            return model;
        }

        public override List<DevicesMongoModel> QueryUserDevice(FinanceBase model)
        {
            //設備編碼集合
            List<DevicesMongoModel> devicesList = null;
            //用戶信息
            ClientsMongoModel mongoModel = MongoOper.QueryUserDevices(model.UserId);

            if(mongoModel!=null && mongoModel.DeviceIdList!=null && mongoModel.DeviceIdList.Count>0)
            {
                //組裝設備編碼集合
                devicesList = (from d in mongoModel.DeviceIdList
                               select new DevicesMongoModel
                               {
                                   Device = d,
                                   MessageSendTag = 0
                               }).ToList();
            }
            return devicesList;
        }

        public override MessageMongoModel CombineData(FinanceBase model, List<DevicesMongoModel> devices, UserRoleEnum userRole, int messageSendTag)
        {
            MessageMongoModel mongoModel = new MessageMongoModel()
            {
                MessageId = model.MessageId,
                MessageTitle = model.MsgTitle,
                MessageContent = model.MsgContent,
                MessageExtras = model.MessageExtras,
                MessageType = model.MessageType,
                UserId = model.UserId,
                UserRole = userRole,
                Devices = devices    //設備集合
            };
            return mongoModel;
        }
    }

3.環境類

定義了一個字典用於存放消息類型Operation和抽象策略類SaveOffLineMessageTemplate<T>的對應關系，字典Value中實際上存放的是具體的策略類（里氏替換原則）。這里就是把switch case中每個消息類型Operation及其對應的分支操作抽象為字典中一對一的關系。

然后利用反射動態的創建具體策略類實例並將其加入字典，每次請求過來時，都會匹配字典中是否存在以此次請求的消息類型Operation為key的項，如果存在就會執行抽象策略類中的AddMessageToMongo方法，實際上就是執行了具體策略類中的操作方法。這樣就間接實

現了switch case根據請求帶來的參數分發到不同的處理類。

此處應該注意的是反射的效率是比較低的，所以環境類SaveOffMessageToMongo<T>的構造函數應該設為static靜態的,保證只有第一次請求時才會執行反射創建對象，而之后的所有請求都不再創建對象。而switch case實現方式中每次請求都會創建對象。這也是使用反射+策略模式的一個優點，避免了創建實例過程中的資源和時間的消耗。

public class SaveOffMessageToMongo<T>
    {
        public static Dictionary<Operation, SaveOffLineMessageTemplate<T>> dicSaveOffMessage;

        #region 利用反射+策略模式解決operation大量的switch case 
        /// <summary>
        /// 利用反射+策略模式解決operation大量的switch case 
        /// </summary>
        static SaveOffMessageToMongo()
        {
            //1.創建一個字典用於存放 消息類型-具體策略
            dicSaveOffMessage = new Dictionary<Operation, SaveOffLineMessageTemplate<T>>();
            //2.獲取類型的 System.Type 對象
            Type abjType = typeof(SaveOffLineMessageTemplate<T>);
            //3.獲取此類型所在的程序集
            Assembly assem = abjType.Assembly;
            //4.遍歷獲取此程序集中所有的類
            foreach (Type t in assem.GetTypes())
            {
                //5.是類並且不是抽象類並且繼承自抽象策略類（只有具體策略類符合）
                if (t.IsClass && !t.IsAbstract && t.IsSubclassOf(abjType))
                {
                    //6.如果符合就創建一個具體策略類的實例，並裝換為抽象策略類類型
                    SaveOffLineMessageTemplate<T> template = Activator.CreateInstance(t) as SaveOffLineMessageTemplate<T>;
                    //7.如果字典中不存在以實例的消息類型Operation為key的項，就添加至字典
                    if (template != null && !dicSaveOffMessage.ContainsKey(template.operation))
                    {
                        dicSaveOffMessage.Add(template.operation, template);
                    }
                }
            }
        } 
        #endregion

        #region 添加消息到MongoDB
        /// <summary>
        /// 添加消息到MongoDB
        /// </summary>
        /// <param name="message">消息</param>
        /// <param name="operation">操作類型</param>
        /// <param name="userRole">用戶類型</param>
        /// <param name="messageSendTag">消息發送標志</param>
        public static void AddMessageToMongo(string message, Operation operation, UserRoleEnum userRole, int messageSendTag = 0)
        {
            //8.如果字典中存在以operation為key的項，就調用對應的抽象策略類中的AddMessageToMongo方法
            if (dicSaveOffMessage.ContainsKey(operation))
            {
                dicSaveOffMessage[operation].AddMessageToMongo(message, userRole, messageSendTag);
            }
        } 
        #endregion
    }

 

 總結：

使用反射+策略模式代替項目中大量的switch case判斷的優點：

1.代碼的擴展性好，當有新的消息類型需要處理時，只需要添加一個具體策略類進行處理即可，完全不必關心環境類的實現。

2.避免了創建實例過程中的資源和時間的消耗。

缺點：

1.反射的效率較低，如果抽象策略類所在的程序集擁有的類較多時，反射效率較低的缺點就會比較明顯。因為需要進行大量的循環遍歷才能找到符合條件的具體策略類。