英文原文：I give the orders around here! 

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

　　在探索如何提高自己的過程中，我學(xué)了很多種語言。大多數(shù)是以面向?qū)ο鬄橹鞯?OO)。

　　然而，讓我驚訝的是，在我讀過的大多數(shù)書本、雜志和網(wǎng)上文章中，有著大量遭透了的被當作面向?qū)ο罄拥拇a。

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

　　在《Holub on Patterns: Learning Design Patterns By Looking At Code》這本書里，Allen Holub 在第一章里有一節(jié)的標題是“為什么 getter 和 setter 方法有害”。他在 JavaWorld 上的一篇文章里也談?wù)摿诉@個問題。對所有的面向?qū)ο蟮某绦騿T來說，這應(yīng)該是一篇“必讀”文章。

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

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

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

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

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

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

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

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

it知識庫：面向?qū)ο缶幊蹋哼@里我說了算！，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。