空調(diào)吸氣和排氣

Java程序員習(xí)慣性地用“ getters”和“ setters”來(lái)修飾類(lèi)，這種做法根深蒂固，以至于幾乎沒(méi)有人質(zhì)疑為什么這樣做或是否應(yīng)該這樣做。 最近，我認(rèn)為最好不要這樣做，并且我開(kāi)始在編寫(xiě)的Java代碼中避免使用它。 在這篇博客文章中，我將解釋原因。 但是首先，要進(jìn)行快速的歷史課程。

JavaBeans

Getters和setters起源于JavaBeans規(guī)范 ，該規(guī)范最初于1996年末發(fā)布，并于1997年8月更新為1.01版。最初的想法是使對(duì)象的創(chuàng)建成為可能，這些對(duì)象可以用作構(gòu)建模塊來(lái)組成應(yīng)用程序。 這個(gè)想法過(guò)去了，“用戶”可以使用某種構(gòu)建器工具連接在一起，并自定義一組JavaBeans組件以一起充當(dāng)應(yīng)用程序。 例如，AWT應(yīng)用程序中的按鈕將是Bean（AWT是Java UI庫(kù)Swing的前身）。 另外，一些JavaBeans更像是常規(guī)應(yīng)用程序，然后可以將它們組合成復(fù)合文檔，因此電子表格bean可以嵌入到網(wǎng)頁(yè)內(nèi)。

當(dāng)遵循以下約定時(shí)，對(duì)象就是JavaBean：

它必須具有一個(gè)零參數(shù)的構(gòu)造函數(shù)，該構(gòu)造函數(shù)不能失敗。

它具有可通過(guò)“ getter”和“ setter”方法訪問(wèn)和更改的屬性。

對(duì)于稱為Foo的bean的任何屬性，訪問(wèn)器方法必須稱為getFoo 。 在布爾屬性的情況下，可以將吸氣劑稱為isFoo 。

Foo的setter方法必須稱為setFoo 。

Bean不必為每個(gè)屬性都同時(shí)提供一個(gè)getter和一個(gè)setter：一個(gè)具有g(shù)etter而沒(méi)有setter的屬性是只讀的； 具有setter且沒(méi)有g(shù)etter的屬性是只寫(xiě)的。

該規(guī)范描述了許多不同的用例，但是從上面的描述可以清楚地看出，JavaBeans被視為具有行為的對(duì)象，而不僅僅是數(shù)據(jù)包。 這個(gè)想法已經(jīng)淡出人們的視線，但是盡管JavaBean被很大程度上遺忘了，但是Java中的getter和setter方法的慣用法仍然存在。

隱喻是錯(cuò)誤的

“獲取”和“設(shè)置”的概念似乎很自然，但這是否正確？ JavaBeans約定使用“ get”來(lái)表示查詢，這是一個(gè)沒(méi)有副作用的操作，但在現(xiàn)實(shí)世界中，getting是一個(gè)會(huì)改變狀態(tài)的動(dòng)作：如果我將一本書(shū)下架，則該書(shū)不再上架。 您可能會(huì)反對(duì)，這只是純粹的學(xué)問(wèn)，但我認(rèn)為這種誤解會(huì)鼓勵(lì)我們錯(cuò)誤地思考我們編寫(xiě)對(duì)象以進(jìn)行交互的方式。 例如，如果我們有一個(gè)Thermometer類(lèi)，那么大多數(shù)Java開(kāi)發(fā)人員都會(huì)編寫(xiě)代碼來(lái)讀取溫度，如下所示：

Temperature t = thermometer.getTemperature();

確實(shí)，“獲取”溫度是溫度計(jì)的工作嗎？ 沒(méi)有！ 溫度計(jì)的作用是測(cè)量溫度。 我為什么要為此努力呢？ 這是因?yàn)椤矮@取”是必要的陳述：它是溫度計(jì)的一項(xiàng)操作說(shuō)明。 但是我們不想指示溫度計(jì)在這里做任何事情； 它已經(jīng)在做它的工作（測(cè)量溫度），我們只想知道它的當(dāng)前讀數(shù)是多少。 閱讀是由我們完成的。 因此，以這種方式編寫(xiě)時(shí)，代碼更加自然：

Temperature t = thermometer.reading();

我認(rèn)為這更好地將責(zé)任歸于責(zé)任。 但是請(qǐng)務(wù)必考慮是否需要訪問(wèn)器，因?yàn)椤?

對(duì)象不是數(shù)據(jù)結(jié)構(gòu)

用getter和setter編寫(xiě)類(lèi)的習(xí)慣對(duì)我們的編碼方式有微妙的影響。 它自然化了我們應(yīng)該進(jìn)入對(duì)象以獲取所需數(shù)據(jù)，對(duì)其進(jìn)行處理，然后使用結(jié)果更新對(duì)象的想法，而不是讓對(duì)象自己執(zhí)行處理。 換句話說(shuō)，它鼓勵(lì)我們將對(duì)象視為數(shù)據(jù)包。 我們通過(guò)getter提取數(shù)據(jù)，并通過(guò)setter更新它們。 同時(shí)，對(duì)數(shù)據(jù)進(jìn)行操作的代碼位于其他位置。

如果我們的編碼習(xí)慣使我們傾向于將對(duì)象視為純數(shù)據(jù)結(jié)構(gòu)，那么ORM框架會(huì)積極地實(shí)施它。 更糟糕的是，如果您使用的是Spring框架–如果您是Java開(kāi)發(fā)人員，那么很有可能–默認(rèn)情況下，它會(huì)將所有bean創(chuàng)建為單例。 （令人困惑的是，Spring bean與JavaBeans無(wú)關(guān)）。 因此，現(xiàn)在您有了一個(gè)由單例對(duì)象組成的系統(tǒng)，該系統(tǒng)在無(wú)行為的數(shù)據(jù)結(jié)構(gòu)上運(yùn)行。 如果您將代碼和數(shù)據(jù)分開(kāi)聽(tīng)起來(lái)像是您所熟悉的編程風(fēng)格，那您就沒(méi)錯(cuò)：我們稱其為過(guò)程編程。

考慮一下這是否是一件好事。 畢竟，Java應(yīng)該是一種面向?qū)ο蟮木幊陶Z(yǔ)言。 OO的一大優(yōu)點(diǎn)是我們可以編寫(xiě)對(duì)象類(lèi)，其名稱和交互作用反映問(wèn)題域。 它使我們能夠編寫(xiě)要解決的問(wèn)題的代碼，而不會(huì)模糊基本編程結(jié)構(gòu)和原始數(shù)據(jù)類(lèi)型背后的全局。 它幫助我們透過(guò)樹(shù)林看木頭。 我們不應(yīng)該放棄這一點(diǎn)。

該怎么做

盡可能停止編寫(xiě)get and set！ 有時(shí)這是適當(dāng)?shù)淖龇?#xff0c;但一定要停止使用IDE的功能來(lái)為您生成getter和setter。 這只是快速執(zhí)行錯(cuò)誤操作的便捷方法。 如果需要在對(duì)象上公開(kāi)某個(gè)屬性，只需將其命名為該屬性，然后還要檢查是否確實(shí)需要公開(kāi)該屬性。 詢問(wèn)為什么要這樣做。 可以將任務(wù)委派給對(duì)象本身嗎？ 例如，假設(shè)我有一個(gè)表示貨幣金額的類(lèi)，并且希望對(duì)一堆交易進(jìn)行匯總：

Amount total = new Amount(transactions.stream().map(Transaction::getAmount).mapToDouble(Amount::getValue).sum());

代替getValue訪問(wèn)器，為什么不給Amount類(lèi)一個(gè)add()方法并讓它為我求和呢？

Amount total = transactions.stream().map(Transaction::getAmount).reduce(Amount.ZERO, Amount::add);

這帶來(lái)了好處–也許您對(duì)使用雙精度表示貨幣金額的想法很感興趣。 沒(méi)錯(cuò)，BigDecimal會(huì)更好。 第二個(gè)示例使此問(wèn)題更易于修復(fù)，因?yàn)閮?nèi)部表示形式得到了更好的封裝。 我們只需要在一處更改它。

也許您想要獲取對(duì)象的數(shù)據(jù)以測(cè)試其是否等于某物。 在這種情況下，請(qǐng)考慮在對(duì)象上實(shí)現(xiàn)equals()方法，并為您測(cè)試是否相等。 如果使用Mockito創(chuàng)建間諜，則無(wú)需使用參數(shù)捕獲器：相反，您可以創(chuàng)建一個(gè)等值的對(duì)象作為示例，并將其直接傳遞給verify語(yǔ)句進(jìn)行比較。

有時(shí)您必須創(chuàng)建訪問(wèn)器。 例如，為了將數(shù)據(jù)持久存儲(chǔ)在數(shù)據(jù)庫(kù)中，您可能需要訪問(wèn)數(shù)據(jù)的原始表示形式。 您是否真的必須遵循獲取/設(shè)置命名約定？ 如果您的回答是“這就是用Java完成的方式”，那么我建議您回頭閱讀JavaBeans規(guī)范。 您是否真的在編寫(xiě)JavaBean以按照規(guī)范描述的方式使用它？ 您是否正在使用期望您的對(duì)象遵循約定的框架或庫(kù)？

必須創(chuàng)建變種器的次數(shù)將減少。 函數(shù)式編程現(xiàn)在正像一股狂潮一樣席卷整個(gè)行業(yè)，而不變數(shù)據(jù)的原理是一個(gè)很好的原則。 它也應(yīng)該應(yīng)用于OO程序。 如果沒(méi)有必要改變狀態(tài)，你應(yīng)該考慮有必要不改變狀態(tài)，所以不用加一個(gè)賦值函數(shù)方法。 當(dāng)您編寫(xiě)導(dǎo)致出現(xiàn)新?tīng)顟B(tài)的代碼時(shí)，將盡可能返回新實(shí)例來(lái)表示新?tīng)顟B(tài)。 例如，BigDecimal實(shí)例上的算術(shù)方法不會(huì)更改其自己的值：它們返回表示其結(jié)果的新BigDecimal實(shí)例。 如今，我們擁有足夠的內(nèi)存和處理能力，可以使這種編程方式變得可行。 而且Spring框架不需要注入依賴方法的setter方法，它也可以通過(guò)構(gòu)造函數(shù)參數(shù)進(jìn)行注入。 實(shí)際上，這種方法是Spring文檔推薦的方法。

某些技術(shù)確實(shí)要求類(lèi)遵循JavaBeans約定。 如果您仍在為視圖層編寫(xiě)JSP頁(yè)面，則EL和JSTL期望響應(yīng)模型對(duì)象具有g(shù)etter方法。 用于將對(duì)象與XML進(jìn)行序列化/反序列化的庫(kù)可能需要它。 ORM框架可能需要它。 由于這些原因而被迫編寫(xiě)數(shù)據(jù)結(jié)構(gòu)時(shí)，建議您將其隱藏在體系結(jié)構(gòu)邊界后面。 當(dāng)對(duì)象泄漏到您的域中時(shí)，不要讓這些數(shù)據(jù)結(jié)構(gòu)偽裝。

結(jié)論

在與使用其他語(yǔ)言工作的程序員交談時(shí)，我經(jīng)常聽(tīng)到他們批評(píng)Java。 他們說(shuō)“太羅y”或“樣板太多”之類(lèi)的話。 Java當(dāng)然有其缺陷，但是當(dāng)我更深入地詢問(wèn)這些批評(píng)時(shí)，我通常會(huì)發(fā)現(xiàn)它們針對(duì)特定的實(shí)踐，而不是針對(duì)該語(yǔ)言的任何內(nèi)在實(shí)踐。 做法不是一成不變的，它們會(huì)隨著時(shí)間的流逝而發(fā)展，不良做法可以得到解決。 我認(rèn)為在Java中隨意使用get和set是一種不好的做法，如果放棄，我們會(huì)編寫(xiě)更好的代碼。

翻譯自: https://www.javacodegeeks.com/2018/03/getters-and-setters-considered-harmful.html

空調(diào)吸氣和排氣

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來(lái)咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的空调吸气和排气_吸气剂和二传手被认为有害的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。