軟體維護與迪米特法則

    最近在維護公司的一箇舊項目的時候，發現有些BUG改了又改，子生孫，孫又生子的。公司裡只要接觸過這個項目的同事都覺得非常的痛苦。一個對象的狀態被七八個地方修改，經常是這邊改成這樣，那邊又改成這樣，這邊對了，那邊又錯了。幾經思考，我認為這是違反了迪米特法則導致的。
    迪米特法則（Law of Demeter）又叫最少知識原則（Least Knowledge Principle 簡寫LKP）就是說，一個對象應當對其它對象有儘可能少的瞭解，也叫做不要和陌生人說話。朋友越多，當然就越好了，在家靠父母，在外靠朋友嘛。為什麼在物件導向設計裡反而成了不好的事情呢？其實這是了對象不受到其它對象太多的影響。就像革命時期情報員只能單線聯絡一樣，如果其中一個被敵人發現了，其他人不會馬上全部都暴露出來。系統裡的對象改了某個方法或者被刪除了，它只會影響到與它有關聯的對象。如果一個對象知道得太多其它的對象，只要其中的某一個對象有改變那它肯定就會受到影響。它知道的對象越多，可能受到影響就會越多。雖然在現代的語言裡（C#、Java等）可以使用介面來隔離變化，但是如果串連口都需要改變的時候，依然還是會受到的影響。遵守 迪米特法則可以使對象本身受到其它對象的影響降低到最少。