設計模式：哪個UML關係最能描述這個類？

考慮下面的類：設計模式：哪個UML關係最能描述這個類？

public class CardGame extends Game { 
    private CardDeck[] cardDecks; 
    public CardGame(int numCardDecks) { 
     super(); 
     cardDecks = new CardDeck[numCardDecks]; 
     for (int i=0; i < numCardDecks; i ++) { 
      cardDecks[i] = new CardDeck(); 
     } 
    } 
}

哪個UML關係最能說明這個類？（？爲什麼）
- 聚合 - 組成 - 泛化 - 工廠

注：我覺得這個單項選擇題測試問題本身沒有明確的規定。

來源

2016-08-03 Yu Chen

你能解釋一下你爲什麼想知道這個嗎？聚合和合成爲模型添加了很少的語義，只有在少數情況下。 –

@YuChen，這看起來像作業。你認爲答案是什麼，爲什麼？ – jaco0646

@ jaco0646非常接近，實際上是Java專業證書的商業模擬測試中的一個問題。我在辯論答案，概括，並發現自己與這裏的其他職業一致。我相信，沒有什麼真正複雜的，反饋意見，還有其他一些錯誤答案的問題已經提交。 –

聚合，合成和泛化是表示不同類型關係即邏輯連接類型的UML（類圖）符號。

您的情況'遊戲'是'CardGame'的泛化; 'CardGame是'遊戲'的專業化。我想說的是，在你的情況下，'CardDecks'與你的'Cardgame'有構成關係，因爲你的卡片是在'CardGame'類中創建的，並且如果你刪除'CardGame'就會被刪除，即「暗含關係，孩子不能獨立於父母而存在「（What is the difference between aggregation, composition and dependency?）。但是，如果您將特定的「CardDecks」存儲在數據庫中，或者如果您試圖對可在其他遊戲中使用這些卡的真實世界進行建模，那麼它就是Aggregation。您的CardDeck類是「工廠方法」，因爲它是創建對象的類。

我不認爲這應該歸類爲設計模式，因爲它是一個設計模式，它必須描述軟件設計中常見問題的循環解決方案。「在軟件工程中，設計模式是軟件設計中常見問題的一個可重複使用的解決方案，設計模式並不是一個完全可以直接轉換爲代碼的設計，它是一個描述或模板，用於如何解決可以在許多不同情況下使用的問題。「（https://sourcemaking.com/design_patterns）

來源

2016-08-03 06:39:32 Kriss

精通，贊同。 –

Game可以推廣CardGame如CardGame從它派生的。

我認爲cardDecks是CardDeck作爲CardGame控制它們的壽命，並且該代碼的上下文中的組合物，它們只能屬於該CardGame。

來源

2016-08-03 07:29:50

Ehm ...你想說遊戲是CardGame的泛化，不是嗎？注意，空三角箭頭應該去遊戲塊。 – Gangnus

當然。也許正確的語言是「遊戲」概括'CardGame''？ –

箭頭被稱爲「泛化」。所以，當然，你的變體更具可讀性和可理解性，但是提問者試圖理解UML俚語......因此，這兩種變體都可以由我自己決定。現在你的答案是正確的，簡短而充分 - 理想的變體。 – Gangnus

設計模式：哪個UML關係最能描述這個類？

回答

相關問題