如果我們有一個類在創建時就實現了equals和hashCode。后來，該類通過新字段進行了增強，當這種情況發生時，很可能equals/hashCode也應該更新。我的問題是這是一種反模式嗎？是否可能存在一些問題，例如，如果該類位于某個庫中，并且有一些代碼考慮舊合同？
3 回答
喵喵時光機
TA貢獻1846條經驗 獲得超7個贊
是的，在修改任何實現時這是一個問題。
當開發人員使用您的類型時，他們將根據當前合同進行開發。如果更新實施不會改變合同，那就沒問題。
但是，如果更新實現確實改變了合同，那就不好了。
如果您的平等合同目前是：
“如果兩個對象具有相同的名稱，那么它們是相等的”
如果兩個對象具有相同的名稱，則它們應該始終相等，因為開發人員將基于此進行開發。
例如，如果您引入一個新字段，id并更新合約以包含該字段：
“如果兩個對象具有相同的名稱和 ID，則它們相等”
如果兩個對象共享相同的名稱但具有不同的 id，則期望名稱相等的系統現在將崩潰。
這不是那個開發商的錯。你的合同規定平等是由名字決定的。他們的代碼遵守了這一點。通過更新合同，您可能會破壞他們的代碼。
如果您的合同規定：
“如果兩個對象的所有屬性都相等，那么它們就相等”
那么引入新屬性不應該破壞軟件，因為開發人員希望實現能夠考慮到任何新屬性，并且會在開發系統時考慮到這一點。
慕運維8079593
TA貢獻1876條經驗 獲得超5個贊
如果班級平等的契約發生變化，它們就需要更新，是的。假設您添加middleName到一個User類，并且您希望基于名字、中間名和姓氏進行平等，而不僅僅是名字和姓氏。但是，添加不影響平等的字段不需要更改。
唯一涉及的代碼是equals()和中的代碼hashcode()，因此除非您編寫了一些糟糕的代碼（例如不使用equals，而是手動比較字段），否則任何現有代碼都會透明地工作。
墨色風雨
TA貢獻1853條經驗 獲得超6個贊
我不認為這是反模式。您所描述的是程序代碼是如何演變的。課程得到更新，提供更多功能和錯誤修復。
在您的情況下， hashCode 通常用于檢查對象相等性，就像 equals 方法的實現一樣。假設舊代碼使用了整個類屬性的一部分，則相等性檢查應保持不變，因為舊代碼不知道新屬性，并且這些屬性未在任何對象中分配。
然而，當一個類被更新并被無法測試的第三方代碼使用時（例如，該類是在maven存儲庫中發布的maven項目的一部分），第三方代碼應該使用該類/項目的版本以確保兼容性。就我個人而言，我見過很多情況，maven 項目被更新，新版本包含完全相同的類/方法簽名，但實現完全不同，從而破壞了代碼。
添加回答
舉報
0/150
提交
取消