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

　　自從 9 歲那年得到第一臺(tái) Commodore 64 家用電腦起，我就開(kāi)始編程。然而，當(dāng)面對(duì)如何寫(xiě)出好的代碼時(shí)，我仍然感覺(jué)自己還有很多要學(xué)的。

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

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

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

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

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

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

　　用這種方式來(lái)暴露數(shù)據(jù)還會(huì)妨礙你重構(gòu)你的類，因?yàn)閷?duì)這樣的屬性的任何修改都意味著會(huì)影響到訪問(wèn)了這個(gè)屬性的其它類。

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

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

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

　　在類里面加入 getter 方法，你的代碼最終會(huì)寫(xiě)成這樣：

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

it知識(shí)庫(kù)：面向?qū)ο缶幊蹋哼@里我說(shuō)了算！，轉(zhuǎn)載需保留來(lái)源！

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