事件的好处~实现对修改的封闭，对扩展的开放

事件是这样的，我觉得用事件来做这事比较好，它很好的遵循了“开闭原则”，当然这并不是最重要的，最重要的应该是它更符合程序开发的原则。

场合：一个订单处理问题，一个订单的产生可能由多种途径生成，Ａ产品走Ａ产品的订单处理过程，完成后显示Ａ产品的订单成功页，Ｂ产品走Ｂ产品的购买流程，完成后，显示Ｂ产品听订单成功页，当然陆续可能会有Ｃ产品，Ｄ产品等等

实现：不考虑订单处理业务，只考虑订单成功页的显示

解决１：由Ａ产品页向订单统一处理程序传递参数，在订单统一处理程序里去判断参数，然后显示信息

解决２：Ａ产品订阅一个事件，去返回订单成功后显示的页面，在订单统一处理程序里触发这个事件，然后自己显示指定信息

从上面两解决解决方法中，可以看到“方法２”更加灵活，更符合面向对象的原则，“原则”不是说说而以的，它确实有它的意思，有它的好处，当有Ｃ产品，Ｄ产品出现时，只需要修改Ｃ和Ｄ对应的部门就可以了，而“单统一处理程序”不需要做修改，而“方法１”则需要修改“单统一处理程序”，这样做下去会使你的程序的维护性和扩展性大打折扣。

代码如下：

/// <summary> 
    /// 返回一条特定的消息 
    /// </summary> 
    public class ReturnMessage 
    { 
        #region Events 
        /// <summary> 
        /// 重定向事件 
        /// </summary> 
        public static event ReturnMsgEventHandler ReturnMsg; 
        #endregion

        #region OnEvents Methods 
        /// <summary> 
        /// 触发重定向事件 
        /// </summary> 
        public static string OnReturnMsg() 
        { 
            if ((ReturnMsg != null)) 
            { 
                return ReturnMsg(); 
            } 
            else 
                return "查看已买到的课程"; 
        } 
        #endregion

    } 
    #region Delegates 
    /// <summary> 
    /// 返回一个字符串消息的委托 
    /// </summary> 
    public delegate string ReturnMsgEventHandler(); 
    #endregion

在主程序中触发时可以这样：

ViewData["Msg"] = ReturnMessage.OnReturnMsg();

在订阅时可以这样：

ReturnMessage.ReturnMsg += new ReturnMsgEventHandler(ReturnMsg_ReturnMsg);

string ReturnMsg_ReturnMsg() 
     { 
         return "产品Ｃ成功"; 
     }

也可以使用匿名方法，写在一行：

ReturnMessage.ReturnMsg +=  delegate(){return "产品Ｃ成功";};

本文转自博客园张占岭（仓储大叔）的博客，原文链接：事件的好处~实现对修改的封闭，对扩展的开放，如需转载请自行联系原博主。