致我们工作中的设计模式之设计原则—开放封闭原则

　　　　好久没有你的信，好久没有人陪我谈心，怀念你柔情似水的眼睛，是我心中最美丽的星星……，最近特别爱听张信哲的这首《别怕我伤心》，不知不觉中发现自己开始怀旧了啊，也有可能是心情不好的时候，念叨着念叨着，就念叨起这首歌啦，或者她的旋律是美好的，让我心有所向，想想，不曾有这样一个让我去牵挂的人，但，却总也如此多情！

         生活在这样一座城市中，我们需要学会去接触不同的人，不同的事，但，时时刻刻又在为自己那颗脆弱的心处处堤防，生怕受到一点伤害。走过平湖烟雨、岁月河山,那些历经酸甜苦辣、遍尝世间百味的人,会更加生动而干净,时间永远都是旁观者,见证着我们所有的过程与结果，我们总想把自己弄得干脆利落，但总也逃离不了种种束缚。

         无论模块是多么的”封闭“，都会存在一些无法对之封闭的变化。既然不可能完全封闭，设计人员必须对于他设计的模块应该对那种变化封闭做出选择。他必须先猜测出最有可能发生的变化种类，然后构造抽象来隔离那些变化。这是《大话设计模式》中对开发封闭原则的描述和定义。多么像我们一个个活生生的人啊。

         对于开发-封闭原则的理解，我的想法就是，基于面向对象技术的编程，我们需要实现代码的可维护性、可复用性、可拓展性、灵活性好的特征，而在进行程序设计的时候，对模块，尤其是类、接口进行一些技术上的处理，来实现为完成类或模块自身特定功能的同时，完成和程序其他模块、接口的耦合。

         简单点理解，类的Public、Private等修饰符就是一种封装，将一些不需要让外界知道的东西封装成私有的，而将一些需要外部访问的封装成public，或者只允许继承的类访问的封装成protected等。

         对于接口而言，就会显得更抽象了，在我编程的最开始几年时间里，我一度不能理解接口的真正用处，后来经过以为前辈的指点，一语道破接口的天机，“接口，不是给自己用的，是用来规范别人的”，单论这句话可能不够严谨，但他瞬刻让我明白了，我在做项目的时候用最原始的三层架构处理程序的时候，我们一般数据访问层都会继承接口，然后逻辑通过接口调用这些代码，如下：

Namespace DataHand
{
    Interface IDAL
    {
        Void Print();
}

Public class DAL : IDAL
{
    Void Print()
    {}
}

Public class BLL
{
    IDAL dal=new DAL();
    dal. Print();
}
}

上面的代码大家肯定都不陌生，最开始想必很多人就是从这种架构开始接触asp.net的分层架构思想的。稍微解释下，当然我这里简化了代码，将IDAL、DAL、BLL这三个类封装到一个命名空间中，实际的项目中大家肯定是将这三个分属不同的DLL中的。然后调用，这样做一个最确切的解释就是，当那一天我们需要更改数据库的时候，比如由MSSQL迁移到Oracle的时候，我们只需要重写DAL就行了，因为BLL层是基于接口编程的。是的无数次，听到这样的解释，这样也是对的，不为错。但或许是本人资历有限，写代码至今，没有遇到过这样的情形，说切换数据库的。呵呵，当然这是题外话了，无论接口实际解决的问题能否起到作用，我们只看这种思想设计，是值得借鉴，将他用到自己项目中去。

         倘若不厌其烦的话，我觉得模块和模块之间都可以用接口层来完成相应的调用关系，当然这又会设计到一个IOC，依赖注入的问题，这个我们可以在后面再来讨论。

         这里依然拿我之前做的一个餐饮ERP系统举例，比如采购单模块，在生成采购单的时候，我们肯定需要网采购单中添加货品，然而添加货品肯定又会涉及调用货品建档基础模块的类代码，简单点说，我们需要添加货品进入采购单，这个时候，我们的通常做法可能就是在采购单模块，甚至是在货品资料模块直接写个方法供采购单来调用。如下：

Public class Product
{
    Public string ProductID{get;set;}
    Public string ProductName{get;set}

    Public IList<Proudct> GetProducts(string txt)
    {
        Return new List<Product>();
}

Public Product GetProduct(string txt)
    {
        Return new Product();
}
}

Public class Order
{
    Public IList<Product> OrderProducts{get;set;}

    Public void AddProductToOrder(Product prd)
    {
        OrderProducts.Add(prd);
}
}

Public class Operator
{
    Public void OperatorOrder()
    {
      Product prd=new Product();
        Order. AddProductToOrder(prd. GetProduct(string.Empty));
}
}

这样的代码有错嘛？没错，写的很好实现了采购单据中添加货品的操作，但是如果有天，Product类中的操作GetProduct发生变化了，这个时候怎么办呢？这种写法耦合性太强，也就是说Order类是在完全知道product类的前提下进行的操作。如果我们用接口来规范呢？

在原有的代码基础上再加一个接口层：

Public interface IProduct
{
    Public Product GetProduct();
}

 

使用一个中间服务类来实现接口：

Public class ProductService: IProduct
{
    Public Product GetProduct()
    {
        Return new Product();
}
}

调用的Operator类的代码可以通过接口来调用：

Public class Operator
{
    Public void OperatorOrder()
    {
      IProduct Iprd=new ProductService ();
        Order. AddProductToOrder(Iprd. GetProduct(string.Empty));
}
}

多言解释几句，云云间其实大家都会发现一个问题，严格按照设计模式的要求来我们的代码量一般情况下肯定会增加，这个就是因为，我们需要更清楚的架构层次和代码结构。在这里我们通过接口来调用一个独立的Service类来实现查找货品的信息，无论说product类如何去改都不会影响到我，从全局上来说，当product类真的发生变化的时候，和具体使用Order类在操作上没有任何影响，即使更改，我们只需要更改Service层的一些方法就可以了。

开放封闭原则其实有很多可以说，上面的这些话，是我最想说的，后面随着我对设计模式更深入的理解和工作中更多的接触，在增加篇幅来写吧。

         简单的分享，或许不是太好，但是我觉得这也是对自己的鞭策。