爲什麼複合模式中的透明度值超過安全性？

Question

我剛剛瞭解到Composite pattern。據我所知，它背後的主要思想是統一處理樹的邊和節點。這意味着結構的「透明度」被重視的，不是「安全」多，導致我們是這樣的：

我理解這個概念，但犧牲安全性的時候想不到的情況透明度是一個很好的選擇。換句話說，在這種情況下，我們是否需要透明度如此糟糕以至於我們願意做出如此嚴肅的犧牲？

Answer 1

在綜合模式的一些討論中，包括「四人幫」的原始描述，透明度對安全性的評價更爲準確。但是四人幫的描述認識到了權衡，並且other influential discussions are more pro-safety。總之，這裏的透明度的情況下：

安全（聲明並不適用於葉只在複合方法）是有代價的：

• 安全組件樹的客戶需要檢查每個部件是否是在遍歷樹時使用Composite（可能使用GoF書籍第168頁上顯示的外部多態技術）。樹的每個客戶端都需要實現這種檢查，或者如果檢查是在訪問者或其中提供的，則需要處理這種複雜性。

• 組件實施者需要選擇每個組件是否是葉或複合，如果他們改變自己的選擇改變自己的代碼。

'透明度'的值（Leaf和Composite的均勻性，即聲明Component中的所有樹操作方法）是安全成本最小化。

• 葉子是罕見或根本不存在：如果有以下爲真

  透明度變得更有價值。例如，在UI工具箱中，可以將子項添加到任何組件（甚至是通常對孩子使用很少的組件，比如複選框），並期望它們被智能化。這樣提供的視覺靈活性可能值得開發人員額外的努力，否則這些開發人員可能是Leafs，Component中的默認實現可能會最大限度地減少額外的工作量。

• 樹的許多用途不需要區分樹葉和複合材料。例如，再次在UI工具箱中，像繪圖這樣的操作可以通過迭代每個Component的可能爲零的子級列表來統一處理Leafs和Composites。

• 運行時（存儲器和CPU），其具有兒童的列表中的每個組件的成本是相對於程序的其餘部分低。

如果上述屬實，均勻性更不負有心人：樹的客戶需要做的少用樹，並在該易用性得到客戶麻煩的情況是罕見的。 UI組件經常會出現這種情況：樹的客戶端需要擔心某個事物是否爲Composite的唯一時候可能是他們構建（添加到）樹時，他們知道什麼時候無論如何，所有的混凝土構件都是如此。

Java Swing作出此選擇：JComponent包括add方法。開發人員只需要不使用JComponents不適合兒童，這對許多組件（例如複選框）是顯而易見的。

如果出現任何相反的情況，那麼葉片和複合材料之間的區分變得更有價值，並且增加管理安全樹的複雜性變得有價值。如果樹葉很常見，並且/或者樹的許多客戶確實需要區分樹葉和複合材料，但類型是「透明的」，並且不能區分（也許GoF應該將這種選擇稱爲不透明而不是透明），但是，那麼客戶更可能會犯錯誤。如果兒童列表太貴，那麼值得讓Component實現者選擇每個組件是Leaf還是Composite。