集合作爲真實世界容器的隱喻

我發現使用集合非常直觀地建模物理容器。我根據物理屬性（如添加元素的數量，基於物理屬性的排序，通過使用位置到元素的貼圖等來定位元素）來重寫/委託添加容量約束的添加方法。集合作爲真實世界容器的隱喻

但是，當我讀取集合類的文檔時，我得到的印象是它不是預期的用途，它只是一個數學結構，而有界列表只是意味着受到元素數量等的限制。

事實上，我認爲我除非能夠連貫地模擬這個集合，否則我可能不應該將這個類作爲集合公開，而只能在內部委託給它。意見？

2010-08-14 tolak

感謝您的回覆。我真的在想這裏的鏈接列表的裝飾器，除了允許的項目數之外，還檢查物理容量。當然，它應該是可迭代的，並允許插入，移除和排序。我至少清楚需要這個內部。也就是說，我的裝飾者至少會成爲一個內部類。整個集裝箱可能比集合更爲複雜，因此不應擴展集裝箱。 – tolak 2010-08-18 05:47:10

不完全確定我已經正確理解了你。我收集你想知道你是否應該公開集合（子類）或包裝它（有一個私人領域）。正如羅伯特所說，它確實取決於案件。這幾乎是你的選擇。儘管如此，我認爲在很多情況下，更好的選擇是不公開集合，因爲約束定義了您正在建模的對象，並且與底層集合不完全一致。簡而言之：你的物品的使用者不需要知道他們正在處理一個收藏品，除非它是真的這是一個具有某些特殊功能的收藏品，例如，具有集合的所有屬性，但只允許一定數量的對象。

來源

2010-08-14 05:38:18

軟件開發中的許多結構都沒有物理對應物。事實上，一些結構和算法是相當抽象的，不能直接在物理世界中建模對象。所以僅僅因爲一個對象不能作爲真實世界中物理對象的合適模型並不一定意味着它不能有效地用於解決計算機程序中的問題。

來源

2010-08-14 05:29:51

事實上，我認爲我除非能夠連貫地模擬這個集合，否則我可能不會將此類作爲集合公開，而只是在內部委託給它。意見？

首先，你不想太過於擔心軟件工程的建模方面。 UML樣式模型（通常）主要用作組織和表達開發人員關於如何實現應用程序的高級概念的一種方式。沒有必要在模型中的類和應用程序代碼中的實現類之間建立嚴格的一對一關係。其次，你不想太過於模仿「真實世界」（即物理）對象及其行爲。大多數在典型應用中使用的「對象」與真實世界沒有真正的聯繫。例如，「文件夾」或「目錄」實際上不過是具有相同名稱的物理對象的類比。計算機概念通常不需要受現實世界對象物理行爲的限制。

最後，有許多軟件工程原因，爲什麼讓您的Java域類擴展標準集合類型是一個壞主意。例如：

集合具有通用行爲，通常不適合在域對象中公開。例如，你通常不希望域對象的組件被添加和刪除。
通過擴展集合類型，您隱式授予您應用程序某些部分的權限，將域對象視爲只是列表或集合或其他內容。
通過擴展集合類，您可以將實現細節硬編碼到您的域API中。例如，您需要決定是擴展ArrayList還是LinkedList，並且改變主意會導致（至少）二進制API不兼容......並且可能更糟糕。

來源

2010-08-14 06:18:22

同意。實際上，儘管所有的貓/狗/動物的例子都在外面，但你想用OO技術建模的最後一件事情就是現實世界。員工成爲管理人員，客戶變得太容易供OO建模，無論任何實際用途。 – EJP 2010-08-14 07:02:25

集合作爲真實世界容器的隱喻

回答

相關問題