這是一種反模式嗎？如果是這樣，爲什如果不是爲什麼不呢？

我正在處理一些代碼，我們正在創建對象模型，但模型具有通用鍵。例如這是一種反模式嗎？如果是這樣，爲什如果不是爲什麼不呢？

class myContact { 
var key; 
var value; 
}

然後在代碼實例它們如下

myContact = new myContact() 
myContact.key = 'address' 
myContact.value = '123 my address' 

myContact2 = new myContact() 
myContact2.key = 'secondAddress' 
myContact2.value = '123 my other address'

，然後將它們連接到一個父對象像

myBank = new company(); 
myBank.addContact(myContact); 
myBank.addContact(myContact2);

以我爲模型是這樣的感覺錯如此鬆散地定義。但是，您從課程名稱中知道這將是某種聯繫信息。

與此同時，我可以看到爲什麼這可能是有用的，就好像我們想在未來添加一種不同類型的聯繫人一樣，這種方法使得這很容易實現。

任何人都可以向我解釋，如果這是好的做法？不好的做法和原因？

我最初的想法：

良好做法

容易在未來擴展接觸的類型。
易於通過myBank的聯繫信息循環並獲取數據。

壞實踐

如果您想更新您通過具有循環特定聯繫人類型找到正確的鑰匙。
我從來沒有寫過這樣的代碼，這就是爲什麼它覺得不好的做法即使它是完全可以接受的。
貧血模型，沒有真正的需要成爲一個類。
沒有定義的密鑰，因此我們無法輕鬆刪除或添加聯繫人，而無需再次搜索全部聯繫人。
沒有定義聯繫人是或應該是什麼。

任何想法將不勝感激。

編輯：添加一些想法，因爲我一個人

來源

2012-05-28 Alan Hollis

我正在慢慢回答我自己的問題，同時使用這種類型的模型.... –

走在我看來，沒有什麼不好用「自定義字段」。它在所有允許用戶定義自己的字段的系統（例如jira，電話簿等）中相當受歡迎。通常有一些基本的，預定義的字段/鍵，例如姓名，ID，電子郵件等，這些字母/鍵用於例如用於搜索或認證。在這個代碼中我唯一不喜歡的是貧血模型。如果你創建一個類myClass（改變這個名字！），然後公開訪問它的所有字段，那麼爲什麼你需要一個類？類是關於封裝。

來源

2012-05-28 23:44:54 piotrek

關於封裝和搜索的好處。我認爲這就是上面的代碼對我來說正在下降的地方。我已經做了一些研究，我相信這將屬於http://en.wikipedia.org/wiki/Entity%E2%80%93attribute%E2%80%93value_model？你會同意嗎？ –

可能。但是當您只能看到一個類和兩個示例時，很難談論實體屬性值模型。當然，最好是用銀行對象來收集'Contact'，而不是用Map'String，String'的銀行，所以我不是說你應該刪除這個類，但是要知道它是什麼。如果它僅爲傳輸值服務器，則使用結構而不是類（公共字段，不允許使用人工獲取器和設置器等）。如果不知道項目未來的計劃，很難提供更好的建議 – piotrek

對我來說，這感覺不對，因爲模型是如此鬆散定義。

「醫生，當我這樣做的時候會感到痛苦」 - 「那麼不要那麼做」。

你需要一個寬鬆的模型來表示它嗎？然後去做。如果沒有，如果你覺得它只是一個負擔，選擇一個更簡單的解決方案。

顯然，目前沒有這方面的需求。未來會出現這種需求的可能性有多大？這樣的重構將如何影響您的代碼庫？你甚至可以對此做出假設嗎？

在這種情況下，在這種情況下應用YAGNI原則可能是有意義的。

來源

2012-05-29 07:49:02

這是一種反模式嗎？如果是這樣，爲什如果不是爲什麼不呢？

回答

相關問題