GOF模式UML圖中的依賴性箭頭

Question

對我來說，或多或少地清楚GOF模式是什麼以及它們如何表現。
但是，我覺得我錯過了全局的東西（使用UML或模式），因爲如果我試圖在腦海中重複它們，我會在許多GOF類圖中繪製額外的箭頭或兩個箭頭。我明白，UML圖不必顯示所有連接，但爲什麼不是所有連接都是簡潔的模式圖。

幾個例子：

工廠方法UML圖：
http://en.wikipedia.org/wiki/Factory_method_pattern

爲什麼沒有關聯線（直的實線箭頭）從創建者到產品？ FactoryMethod有一個註釋：「product = FactoryMethod（）」。這意味着創作者跟蹤產品。爲什麼UML中沒有連接？

Command模式UML圖：
http://en.wikipedia.org/wiki/Command_pattern

爲什麼祈求孤立？客戶端與Receiver相關聯，取決於具體命令，但它需要將該命令傳遞給Invoker。爲什麼Client和Invoker之間沒有連接？

感謝您的回答。

Answer 1

你讓結構與行爲混淆。

關聯意味着結構依賴性，通常是「有」關係。 A有一個B.然而，這更像是「比爾有一個手指」而不是「比爾有一個錢包」。比爾有時可能會有一個錢包，但這不是結構上將法案界定爲人類的東西。

Creator是否有產品？不，不是結構性的。 Concreate Creator也不是。他們實例化一個產品，然後返回它（我不確定一個實現關聯在那裏是適當的，從來沒有想過返回一些東西來實現它）。他們在大多數情況下不會跟蹤產品。

考慮一個廚師類，它創建一個Meal對象。廚師在將食物送回客戶類後是否跟蹤膳食？不，他正在下一頓飯。因此，廚師和餐食之間沒有關聯。

是的，確實是一位廚師臨時擁有一頓飯，但這頓飯不是廚師的結構部分。他只構造膳食並將其交給消費者。對象圖顯示了對象的結構，而不是對象的方法。這是一種不同的圖，比如活動圖。

至於你的命令模式問題，調用者依賴於接口，而不是命令對象本身。由於Invoker僅依賴於一個接口，因此可以將它傳遞給實現該接口的任何類型的對象。即使它假裝成一個命令，它也不一定是一個命令。

調用者不知道它調用什麼，所以沒有依賴關係，也沒有關聯。舉個例子，假設有人蒙着眼睛，並要求你找出他們給你的東西。你可能能夠知道有多少物體，但有些可能不是。例如，你可能不知道麪包麪糰和playdough之間的區別，或者是一個大的桔子和一個小葡萄柚。對於所有意圖和目的，一個大的桔子和一個小柚子實現相同的觸覺界面，但是當你執行它們（吃它們）時它們會產生不同的結果。