小菜编程成长记（十二 有了门面，程序员的程序会更加体面！）

系列文章导航：

四大发明之活字印刷——面向对象思想的胜利

小菜编程成长记（一 面试受挫——代码无错就是好？）

小菜编程成长记（二 代码规范、重构）

小菜编程成长记（三 复制VS复用）

小菜编程成长记（四 业务的封装）

小菜编程成长记（五 体会简单工厂模式的美妙）

小菜编程成长记（五 体会简单工厂模式的美妙）

小菜编程成长记（五 体会简单工厂模式的美妙）

小菜编程成长记（六 工厂不好用了？）

小菜编程成长记（七 用“策略模式”是一种好策略）

小菜编程成长记（八 反射——程序员的快乐！）

小菜编程成长记（九 会修电脑不会修收音机？——聊设计模式原则）

小菜编程成长记（十 三层架构，分层开发）

小菜编程成长记（十一 无熟人难办事？——聊设计模式迪米特法则）

小菜编程成长记（十二 有了门面，程序员的程序会更加体面！）

小菜编程成长记（十三 设计模式不能戏说！设计模式怎就不能戏说？）

（续上篇）
　　大鸟说道：“实际上没有学过设计模式去理解三层架构会有失偏颇的，毕竟分层是更高一级别的模式，所谓的架构模式。不过在程序中，有意识的遵循设计原则，却也可以有效的做出好的设计。”
      “不要告诉我，刚才讲的‘迪米特法则’就会在分层中用得上？”小菜说。
      “当然用得上，否则讲它干吗，你当我是在安慰你而临时编个法则来骗骗你呀？来，再来看看你上次写的代码。”

Code
private void Form1_Load(object sender, EventArgs e)
 {
     //读配置文件
     ds = new DataSet();
     ds.ReadXml(Application.StartupPath + "\\CashAcceptType.xml");
     //将读取到的记录绑定到下拉列表框中
     foreach (DataRowView dr in ds.Tables[0].DefaultView)
     {
         cbxType.Items.Add(dr["name"].ToString());
    }
    cbxType.SelectedIndex = 0;
}

　　“这是Form_Load的代码，里面有没有什么与界面无关的东西？”大鸟问道。
      “第4、5行是读配置文件的代码，它应该属于DAL层。对吧？”
      “很好，再看下面的这段，里面又有哪些呢？”

Code
private void btnOk_Click(object sender, EventArgs e)
 {
     CashContext cc = new CashContext();
     //根据用户的选项，查询用户选择项的相关行
     DataRow dr = ((DataRow[])ds.Tables[0].Select("name='" + cbxType.SelectedItem.ToString()+"'"))[0];
     //声明一个参数的对象数组
    object[] args =null;
     //若有参数，则将其分割成字符串数组，用于实例化时所用的参数
     if (dr["para"].ToString() != "")
        args = dr["para"].ToString().Split(',');
    //通过反射实例化出相应的算法对象
    cc.setBehavior((CashSuper)Assembly.Load("商场管理软件").CreateInstance("商场管理软件." + dr["class"].ToString(), 
                        false, BindingFlags.Default, null, args, null, null));
    
    double totalPrices = 0d;
    totalPrices = cc.GetResult(Convert.ToDouble(txtPrice.Text) * Convert.ToDouble(txtNum.Text));
    total = total + totalPrices;
    lbxList.Items.Add("单价：" + txtPrice.Text + " 数量：" + txtNum.Text + " "+cbxType.SelectedItem+ " 合计：" + totalPrices.ToString());
    lblResult.Text = total.ToString();
}

　　“这里3-13行，是为确定哪种算法而创建CashContext对象，其中用到了反射技术，为计算做准备。第16行是真正的计算打折价或返利，17-19是界面显示的部分。所以应该把3-16行都搬到BLL层去。不过，我还有些疑问，这样做会让配置文件的数据要先从DAL转到BLL，再转到表示层，多麻烦呀，什么不直接表示层读DAL，它想要数据就去读DAL，它想算结果就去请求BLL处理？”
      “那是说明你没有真的了解什么叫迪米特法则，象你那样说，不就等于，你小菜又要认识小张，又要认识小李了，这不就耦合过度吗？本来你只需要认识一个人就可以了，这样依赖才会小呀！”
      “可是我就得在BLL里写一个专门返回从DAL里得到数据的方法，这个方法不属于现在的任何类，我就还得再写一个类来做这种传声筒的角色。而且由于界面还要涉及到其它的类，如CashContext，感觉UI和BLL耦合还是很高。”
      “说得没错，你的确是讲到点子上了，由于表示层UI需要与BLL有两个类进行交互，这是很麻烦，不过前辈们就想了了一个较好的办法，另一个设计模式，‘门面模式’（Facade）或叫外观模式”

　　（以下源自吕震宇 博客）
　　门面模式要求一个子系统的外部与其内部的通信必须通过一个统一的门面(Facade)对象进行。门面模式提供一个高层次的接口，使得子系统更易于使用。 

　　门面模式的结构

　　门面模式是对象的结构模式。门面模式没有一个一般化的类图描述，下图演示了一个门面模式的示意性对象图：

　　在这个对象图中，出现了两个角色：

　　门面(Facade)角色：客户端可以调用这个角色的方法。此角色知晓相关的(一个或者多个)子系统的功能和责任。在正常情况下，本角色会将所有从客户端发来的请求委派到相应的子系统去。

　　子系统(subsystem)角色：可以同时有一个或者多个子系统。每一个子系统都不是一个单独的类，而是一个类的集合。每一个子系统都可以被客户端直接调用，或者被门面角色调用。子系统并不知道门面的存在，对于子系统而言，门面仅仅是另外一个客户端而已。

　　“哦，你这样一讲，我就明白了。”小菜说，“上篇所讲的IT部，其实可以由部门主管就是门面，我们只需要找到部门主管，就可以通过他安排相关的人来提供服务，我们不需要了解IT部的具体情况了。”
      “其实现实中这样的例子很多。比如以前上海市没有新闻发言人，当要到春运时，所有的记者都跑到交通部去了解信息，当有非典或禽流感时，所有的记者又跑到卫生部去打听情况，突然这时候楼市大跌，记者们又得马不停蹄前往建设部收集新闻。辛苦呀，有什么办法呢，吃这口饭的。但其实辛苦地又何止只是记者。各个政府部门都需要专人来应付这些记者，不能多说话，不能说错话，但也不能不说话。也辛苦呀，谁叫他们是政府呢。”大鸟仿佛自己感同身受似的描述着，“于是，新闻发言人横空出世，一位知识女性焦扬，代表上海市政府发言，从此，老记们不需要头顶骄阳奔跑于各大政府部门之间，只需要天天等在新闻发言厅门口守着就可以写出准确及时的新闻。而政府部门也不用专人来应付老记们的围追堵截，有更多的时间为人民做实事办好事。这里就只辛苦一个人。”