面向對象編程：這里我說了算！

來源: 外刊IT評論發布時間: 2012-05-31 06:53 閱讀: 3709 次推薦: 4 原文鏈接 [收藏]

　　自從 9 歲那年得到第一臺 Commodore 64 家用電腦起，我就開始編程。然而，當面對如何寫出好的代碼時，我仍然感覺自己還有很多要學的。

　　在探索如何提高自己的過程中，我學了很多種語言。大多數是以面向對象為主的(OO)。

　　然而，讓我驚訝的是，在我讀過的大多數書本、雜志和網上文章中，有著大量遭透了的被當作面向對象例子的代碼。

　　這些代碼中，我看到的最多被違反的原則是“命令，不要去詢問(Tell, Don’t Ask)”原則。這個原則講的是，一個對象應該命令其它對象該做什么，而不是去查詢其它對象的狀態來決定做什么(查詢其它對象的狀態來決定做什么也被稱作‘功能嫉妒（Feature Envy）’)。在面向對象的編程中，一個對象被定義成由對象狀態和操作這個狀態的方法組成。

　　在《Holub on Patterns: Learning Design Patterns By Looking At Code》這本書里，Allen Holub 在第一章里有一節的標題是“為什么 getter 和 setter 方法有害”。他在 JavaWorld 上的一篇文章里也談論了這個問題。對所有的面向對象的程序員來說，這應該是一篇“必讀”文章。

　　我有一些程序員同事，他們在一個對象上第一步聲明了屬性后，第二步就是添加 getter 和 setter 方法。JavaBean 規范對于這種文化的推廣負于很大的責任。人們認為這是一種能讓你寫出可復用的模塊化組建的好方法，但這已是很多年前的事了，時過境遷。

　　寫帶有 getter 和 setter 方法的類會導致過程式的代碼。通過 getter 和 setter 來獲取數據進行操作的邏輯最終會遍布整個應用，進而經常導致應用內的重復(這違反了另外一個原則：DRY——不要自我重復(Don’t Repeat Yourself))。這會致使產生很難維護的代碼，當你對一個類做任何修改時，都會在整個應用內造成連鎖式的牽連。

　　用這種方式來暴露數據還會妨礙你重構你的類，因為對這樣的屬性的任何修改都意味著會影響到訪問了這個屬性的其它類。

　　違反“命令，不要去詢問”原則的另外一個副作用是，你的探詢最終變成嚴重依賴狀態信息并帶有很多前提條件。這會讓人很難理解你究竟詢問的是什么。

　　你很可能會最終違反的第三個原則是，盡少知道(Least Knowledge)原則，也叫做得墨忒耳定律(Law Of Demeter)。這個定律可以總結為下面一句好：

一個類應該只跟它的直接朋友通話，不要跟陌生人說話。

　　在類里面加入 getter 方法，你的代碼最終會寫成這樣：

if (person.getAddress () .getCountry () == "Australia") {

　　這違反了得墨忒耳定律，因為這個調用者跟 Person 過于親密。它知道 Person 里有一個 Address，而 Address 里還有一個 country。它實際上應該寫成這樣：

if (person.livesIn ("Australia")) {

　　這并不違反得墨忒耳定律，因為這個調用者只跟它的直接朋友 Person 通話，而且它不知道內部情況。從“命令，不要詢問”的視角來看，這也是更好，因為確定這個 person 是否居住在 Australia 的邏輯被隱藏到了 Person 里，如果我們改變 Person 里存儲國家信息的方式，這將不會影響任何依賴這個信息的其它類。

　　另外一個這樣寫代碼的好處是，它把我們的意圖顯示的很清楚。這是我會在以后的時間里討論的另外一個話題。

　　為了避免違反“命令，不要去詢問”原則，有幾樣事情你要記在心里。