我刚刚了解到复合图案 https://sourcemaking.com/design_patterns/composite。据我了解，其背后的主要思想是统一处理树的边和节点。这意味着结构的“透明度”比“安全性”更有价值，导致我们得到这样的结果：
我理解这个概念，但想不出在什么情况下为了透明度而牺牲安全会是一个不错的选择。换句话说，在什么情况下我们如此需要透明度以至于我们愿意做出如此重大的牺牲？
更准确地说，在复合模式的一些讨论中，包括四人帮的原始描述，透明度比安全性更重要。但四人帮的描述认识到了这种权衡，并且其他有影响力的讨论更支持安全 http://c2.com/cgi/wiki?CompositePattern。无论如何，这是透明度的情况：
安全性（仅在 Composite 中声明不适用于 Leaf 的方法）有成本：
“透明度”（Leaf 和 Composite 的一致性，即在 Component 中声明所有树操作方法）的价值在于最小化安全成本。
如果满足以下任一条件，透明度就会变得更有价值：
叶子很少见或根本不存在。例如，在 UI 工具包中，可以将子组件添加到任何组件（甚至是通常对子组件几乎没有用处的组件，例如复选框），并期望它们能够智能地呈现。由此提供的视觉灵活性可能值得开发人员付出额外的努力，否则叶子将是叶子，并且组件中的默认实现可能会最大限度地减少额外的努力。
树的许多用途不需要区分叶子和复合材料。例如，在 UI 工具包中，像绘图这样的操作可以通过迭代每个组件可能为零长度的子组件列表来统一处理叶子和复合组件。
相对于程序的其余部分，具有子级列表的每个组件的运行时（内存和 CPU）成本较低。
如果上述情况属实，那么一致性会带来更多回报：树的客户端需要做更少的事情来使用树，并且这种易用性给客户端带来麻烦的情况很少见。 UI 组件通常会出现这种情况：树的客户端唯一需要担心某些东西是否是 Composite 的时候可能是在他们构建（添加到）树时，此时他们知道什么无论如何，所有具体组件都是如此。
Java Swing 做出了这样的选择：JComponent包括add方法。开发人员只需不要将它们与JComponents不适合儿童，这对于许多组件（同样，例如复选框）来说是显而易见的。
如果出现任何相反的情况，那么区分叶子和复合材料就变得更有价值，并且管理安全树的复杂性变得值得增加。如果叶子是常见的和/或树的许多客户端确实需要区分叶子和复合材料，但类型是“透明”的并且无法进行区分（也许 GoF 应该称此选择为不透明而不是透明），那么客户就更有可能犯错误。如果子级列表太昂贵，那么值得让组件实现者选择每个组件是叶组件还是复合组件。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
