（續上篇）
　　次日傍晚，小菜敲開了大鳥家的門。
      “回來啦！怎么樣？第一天上班感受多吧。”大鳥關心的問道。
      “感受真是多哦！！！”小菜一臉的不屑一顧。
      “怎么了？受委屈了嗎。說說看怎么回事？”
      “委屈談不上，就感覺公司氛圍不是很好。我一大早就到他們公司，正好我的主管出去了不在公司。人事處的小楊讓我填了表后，就帶我到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與模式》，一本國人寫的難得的好書，給出“購買”評級。