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

（续上篇）
           次日傍晚，小菜敲开了大鸟家的门。
        “回来啦！怎么样？第一天上班感受多吧。”大鸟关心的问道。
        “感受真是多哦！！！”小菜一脸的不屑一顾。
        “怎么了？受委屈了吗。说说看怎么会事？”
        “委屈谈不上，就感觉公司氛围不是很好。我一大早就到他们公司，正好我的主管出去了不在公司。人事处的小杨让我填了表后，就带我到IT部领取电脑，她向我介绍了一个叫‘小张’的同事认识，说我跟他办领取电脑的手续就可以了。小张还蛮客气，正打算要装电脑的时候，来了个电话，叫他马上去一个客户那里处理PC故障，他说要我等等，回来帮我弄。我坐了一上午，都没有见他回来，但我发现IT部其实人还有两个人，他们都在电脑前，一个忙于QQ，一个好象在看新闻。我去问人事的小杨，可不可以请其他人帮我办理领取手续，她说她现在也在忙，让我自己去找一下IT部的小李，他或许有空。我又返回IT部办公室，问小李帮忙，小李先是忙着回了两个QQ后才接过我领取电脑的单子，看到上面写着‘张XX’负责电脑领取安装工作，于是说这个事是小张负责的，他不管，叫我还是等小张回来再做吧。我就这样又像皮球一样被踢到桌边继续等待，还好我带着一本《重构》在看，不然真要郁闷死。小张快到下班的时候才回来，开始帮我装系统，加域，设置密码等，其实也就Gohost恢复再设置一下，差不多半小时就弄好了。”小菜感叹的说道，“就这样，我这人生一个最重要的第一次就这么渡过了。”
        “哈哈，就业、结婚、生子，人生三大事，你这第一大事的第一次是够郁闷的。”大鸟同情道，“不过现实社会就是这样的，他们又不认识你，不给你面子，也是很正常的。就象现在曹启泰主持的电视《上班这点事》节目，当中可聊可学之事还真不少，上班可不是上学，复杂着呢。罢了罢了，谁叫你运气不好，你的主管在公司，事情就会好办多了。”
       “不过，这家公司让你感觉不好原因在于管理上存在一些问题。”大鸟接着说，“这倒是让我想起来我们设计模式的一个原则，你的这个经历完全可以体现这个原则观点。”
       “哦，是什么原则？”小菜情绪被调动了起来，“你怎么什么事都可以和软件设计模式搭界呢？”
       “，大鸟我显然不是吹出来的……”大鸟洋洋得意道。
       “啧啧，行了行了，大鸟你强！！！不是吹的，是天生的！，快点说说，什么原则？”小菜对大鸟的吹鸟腔调颇为不满，希望快些进入正题。
       “你到了公司，通过人事部小杨，认识了IT部小张，这时，你已认识了两个人。但因没人介绍你并不认识IT部小李。而既然小张小李都属于IT部，本应该都可以给你装系统配帐号的，但却因小张有事，而你又不认识小李，而造成你的人生第一次大大损失，你说我分析得对吧？”
       “你这都是废话，都是我告诉你的事情，哪有什么分析。”小菜失望道。
       “如果你同时认识小张和小李，那么任何一人有空都可以帮你搞定了，你说对吧？”
       “还是废话。”
       “这就说明，你如果把人际关系搞好，所谓‘无熟人难办事’，你在IT部‘有人’，不就万事不愁了吗？”大鸟一脸坏笑。
       “大鸟，你到底想说什么？我要是有关系，对公司所有人都熟悉，还用得着你说呀。”
       “小菜，瞧你急的，其实我想说的是，如果IT部有一个主管，负责分配任务，不管任何需要IT部配合的工作都让主管安排，不就没有问题了吗？”大鸟开始正经起来。
       “你的意思是说，如果小杨找到的是IT的主管，那么就算小张没空，还可以通过主管安排小李去做，是吗？”
       “对头（四川方言发音）。”大鸟笑着鼓励道。
       “我明白了，关键在于公司里可能没有IT主管，他们都是找到谁，就请谁去工作，如果都熟悉，有事可以协调着办，如果不熟悉，那么就会出现我碰到的情况了，有人忙死，有人空着，而我在等待。”
       “没有管理，单人情协调也很难办成事的。如果公司IT部就一个小张，那什么问题也没有，只不过效率低些。后来再来个小李，那工作是叫谁去做呢？外人又不知道他们两人谁忙谁闲的，于是抱怨、推诿、批评就随风而至。要是三个人在IT部还没有管理人员，则更加麻烦了。正所谓一个和尚挑水吃，两个和尚抬水吃，三个和尚没水吃。”
       “看来哪怕两个人，也应该有管理才好。我知道你的意思了，不过这是管理问题，和设计模式有关系吗？”
       “急什么，还没讲完呢？就算有IT主管，如果主管正好不在办公室怎么办呢？公司几十号人用电脑，时时刻刻都有可能出故障，电话过来找主管，人不在，难道就不解决问题了？”
       “这个，看来需要规章制度，不管主管在不在，谁有空先去处理，过后汇报给主管，再来进行工作协调。”小菜也学着分析起来。
       “是呀，就像有人在路上被车撞了，送到医院，难道还要问清楚有没有钱才给治疗吗，‘人命大于天’，同样的，在软件公司，‘电脑命大于天’，开发人员工资平均算下来每天按数百记的，耽误一天半天，实在是公司的大损失呀——所以你想过应该怎么办？”
       “我觉得，不管认不认识IT部的人，我只要电话或亲自找到IT部，他们都应该想办法帮我解决问题。”
       “好，说得没错，那你打电话时，怎么说呢？是说‘经理在吗？……小张在吗？……’，还是‘IT部是吧，我是小菜，电脑已坏，再不修理，软件歇菜。’”
      “，当然是软件歇菜来得更好！你这家伙，就拿我开心！”
      “这样子的话，公司不管任何人，找IT部就可以了，不管认识不认识人，反正他们会想办法找人来解决。”
      “哦，我明白了，我真的明白了。你的意思是说，IT部代表是抽象类或接口，小张小李代表是具体类，之前你在分析会修电脑不会修收音机里讲的依赖倒置原则，即面向接口编程，不要面向实现编程就是这个意思？”小菜，兴奋异常。
      “当然，这个原则也是满足的，不过我今天想讲的是另一个原则：‘迪米特法则（LoD）’ 也叫最少知识原则，简单的说，就是如果两个类不必彼此直接通信，那么这两个类就不应当发生直接的相互作用。如果其中一个类需要调用另一个类的某一个方法的话，可以通过第三者转发这个调用。其实道理就是你今天碰到的这个例子，你第一天去公司，怎么会认识IT部的人呢，如果公司有很好的管理，那么应该是人事的小杨打个电话到IT部，告诉主管安排人给小菜你装电脑，就算开始是小张负责，他临时有急事，主管也可以再安排小李来处理，如果小李当时不忙的话。其实迪米特法则还是在讲如何减少耦合的问题，类之间的耦合越弱，越有利于复用，一个处在弱耦合的类被修改，不会对有关系的类造成波及。也就是说，信息的隐藏促进了软件的复用。”
        “明白，由于IT部是抽象的，哪怕里面的人都离职换了新人，我的电脑出问题也还是可以找IT部解决，而不需要认识其中的同事，纯靠关系帮忙了。就算需要认识，我也只要认识IT部的主管就可以了，由他来安排工作。”
       “小菜动机不纯吗！你不会是希望小李快些被炒鱿鱼吧？哈！”大鸟瞧着小菜笑道。
       “去！！！我是那样的人吗？好了，你昨天说过，要我改商场收银代码为三层架构，有些麻烦的。我得想想。”

（待续）
注：有回复说到《小菜编程成长记》系列讲问题不透，其实这是正常的，毕竟这不是上课，而是在写对话，聊天而已，建议看文章后若有学习的想法再去搜索相关主题研究，千万不能认为看了小菜系列就可以学懂设计模式。伍迷更希望是在你工作学习辛苦这余，看看《小菜》系列，调剂一下笑笑而已。另：本文迪米特法则知识来自《Java与模式》，一本国人写的难得的好书，给出“购买”评级。