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

　　自從 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") {

it知識庫：面向對象編程：這里我說了算！，轉載需保留來源！

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