design-patterns - 复合模式是 SOLID 吗？

Question

复合模式中的叶子实现了组件接口(interface)，包括Add , Remove , 和 GetChild Leaf 永远不会使用的方法。这似乎违反了接口(interface)隔离原则。

复合模式的用法也是如此 SOLID ?

复合模式链接:http://www.dofactory.com/Patterns/PatternComposite.aspx

Answer 1

您的链接和大多数书籍中描述的模式中真正的气味是 Component具有 Composite 的方法.我认为这可能是因为该模式相当古老，并且多年来一直以这种方式重复。我的看法是，只有 Composite应该有任何与合成相关的方法。

我曾经将棋盘游戏转换为电脑游戏。棋子被放置在地球 map 上，分成六边形。 99% 的六边形代表一个位置。不幸的是，一些六边形包含多个位置，例如，一些六边形内部有几个岛屿。我使用复合模式来表示这些位置，但不像您的链接上描述的那样。它是这样的(在 Java 中):

public interface Location {
   Set<Army> getArmies();
}

public class SingleLocation implements Location {

   public Set<Army> getArmies() {
      return armies ;
   }

   private Set<Army> armies = new HashSet<Army>();
}

public class CompositeLocation implements Location {

   public Set<Army> getArmies() {

      Set<Army> armies = new HashSet<Army>();

      for(Location subLocation: subLocations) {
         armies.addAll(subLocation.getArmies());
      }

      return armies;
   }

   public void addSubLocation(Location location) {
      subLocations.add(location);
   }

   private Set<Location> subLocations = new HashSet<Location>();
}

请注意，只有 Composite有合成方法，甚至没有向大多数客户公开它有 child 的事实(在这个例子中，客户只想要一个位置的军队列表 - 他们在许多子位置的事实是无关紧要的)。

请记住，设计模式并不是您必须完全实现的固定不变的东西。把它们想象成食谱。当您在 cooking 时遵循食谱时，您当然可以完全遵循它。然而，一些厨师会在食谱上加入自己的曲折。其他人甚至不会看它，因为他们是专家，甚至可以不假思索地按照食谱的精神把一些东西放在一起。设计模式也是如此。它们是可延展的食谱。

您也可以将这些 SOLID 原则走得太远。如果您阅读 Robert Martin 的文章，他会指出，不加思索地全面应用这些原则会产生过于复杂的代码。软件是通过一系列权衡和平衡来设计的——有时你会放弃纯 SOLID，因为它会产生更简洁、更简单的代码。如果您要使您的代码完美封装、灵活、解耦等，您将发明一种新的编程语言:-)