圖形限制 - 我應該使用裝飾器嗎？

我有一個功能AdjacencyListGraph類遵守定義的接口GraphStructure。爲了層上這一（例如無環的，非空的，獨特的頂點數據等。），I可以看到兩個可能路線，每一個利用所述GraphStructure接口的限制：圖形限制 - 我應該使用裝飾器嗎？

創建單個類（「ControlledGraph」），它具有一組指定各種可能限制的位標記。處理這個類的所有限制。如果新的限制要求變得明顯，更新課程。
使用裝飾模式（DI，本質上）爲客戶類可能希望使用的每個單獨的限制創建單獨的類實現。這樣做的好處是我們堅持單一責任原則。

我會傾向於後者，但通過Jove !,我討厭裝飾者模式。這是混亂的縮影，海事組織。事實上，這完全取決於在最糟糕的情況下可能會應用多少裝飾器 - 到目前爲止，計數是七（我在此階段已經認識到的離散限制的數量）。裝飾器的另一個問題是，我將不得不在每個...單個裝飾器類中進行接口方法包裝。呸。

你會去哪，如果？或者，如果你能提出一些更優雅的解決方案，那將是值得歡迎的。

編輯：在我看來，使用建議的ControlledGraph類與戰略模式可能有助於這裏...某種模板方法/函子設置，與各個位應用單獨的控件在各種圖形 - 規範接口方法。還是我失去了陰謀？

來源

2010-03-24 Arcane Engineer

@尼克Wiggill：我會去裝飾（可用於添加和不知道，刪除責任），但爲什麼恨它？這與雜亂的反面相反：沒有裝飾者，你會在你的ControlledGraph中出現混亂和廚房水槽。請注意，現代IDE可以以* one *快捷方式生成對包裝主題的所有委託調用。 OO正確完成的一個重點是能夠適應不斷變化的需求。如果需求被刻在石頭上，那麼取決於使用位域的實現（ControlledGraph）可能沒問題，但這不是OO。 – SyntaxT3rr0r 2010-03-24 22:48:04

我同意你的看法，這就是我提到SRP的原因。我可以告訴你，我已經有了這個特定實現的半完整版本，並且它不是很漂亮。但看到我的答案在下面，你會看到一個更優雅的解決方案，它封裝了每個限制的功能，提供了一個更加可擴展的體系結構，並且沒有裝飾器的混亂（它是混亂的 - 我很抱歉，但未定級別的構造函數嵌套只是簡單的愚蠢）。 – 2010-03-24 23:06:43

啊，我現在看到它。 ControlledGraph類中的策略模式的確是一種可行的方式。

每個限制是一個離散的策略類。儘管大多數方法都是空的（例如，一個非循環限制只對使用addEdge（）來防止循環插入感興趣，但其他方法會留空），這些都實現了整個GraphStructure接口。

每次ControlledGraph都調用其中一個接口方法時，它將調用其包含的每個策略/限制的匹配方法。顯然，它可能只有每一種策略中的一種。

來源

2010-03-24 23:02:09

圖形限制 - 我應該使用裝飾器嗎？

回答

相關問題