复合图案是否牢固? [英] Is the Composite Pattern SOLID?

问题描述

复合模式中的叶子实现了Component接口，包括叶子永远不会使用的Add，Remove和GetChild方法.这似乎违反了接口隔离原则.

A Leaf in the Composite Pattern implements the Component interface, including Add, Remove, and GetChild methods that a Leaf is never going to use. This seems to be a violation of the Interface Segregation Principle.

复合模式的用法也是如此

So is the usage of Composite Pattern SOLID?

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

推荐答案

链接和大多数书籍中所描绘的图案中的真实气味是Component具有Composite的方法.我认为这可能是因为该模式已经相当古老，并且已经以这种方式重复了很多年.我的看法是，只有Composite应该具有与合成有关的任何方法.

The real smell in the pattern as depicted in your link and most books is that Component has the methods of a Composite. I think this is probably because the pattern is fairly old and has been repeated that way for years. My take is that only the Composite should have any methods related to compositing.

我曾经将棋盘游戏转换为计算机游戏.将游戏棋子放置在地球地图上，分成六边形.所有六边形的99％代表一个位置.不幸的是，一些六角形包含多个位置，例如，一些六角形内部有几个孤岛.我使用复合模式来表示这些位置，但未如您的链接中所示.就像这样(在Java中):

I once converted a board game over to a computer game. The playing pieces were placed on a map of earth, divided up into hexagons. 99% of all hexagons represented a single location. Unfortunately, a few of the hexagons contained multiple locations, for example, some had a couple islands inside them. I used the composite pattern to represent these locations, but not as depicted on your link. It was something like this (in 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具有合成方法，并且甚至没有向大多数客户公开其拥有子代的事实(在此示例中，客户只希望从某个位置获得军队列表-在许多子位置是无关紧要的.

Note that only the Composite has compositing methods, and doesn't even expose the fact that it has children to most clients (in this example, the client only wants a list of Armies from a location - the fact that they are at many sub-locations is irrelevant).

请记住，设计模式并不是必须确切实现的固定条件.把它们当作食谱.当您在烹饪时遵循食谱时，您当然可以完全遵循它.但是，有些厨师会在食谱上加诸于曲折.其他人甚至不会去看它，因为他们是专家，可以在不考虑它的情况下将某些东西混在一起.设计模式也是如此.它们是可塑的食谱.

Keep in mind design patterns are not set-in-stone things you must implement exactly. Think of them as recipes. When you follow a recipe while cooking, you certainly can just follow it exactly. However, some cooks will throw in their own twists on the recipe. Others won't even look at it because they are experts and can throw something together in the spirit of the recipe without even thinking about it. The same goes for design patterns. They are malleable recipes.

您也可以将那些SOLID原则介绍得太远.如果您阅读罗伯特·马丁(Robert Martin)的文章，他指出，不加任何考虑地全面应用这些原则将产生过于复杂的代码.软件是通过一系列权衡和平衡而设计的-有时您会放弃纯SOLID，因为它会产生更简洁，更简单的代码.如果要使代码完美地封装，灵活，解耦等，您将发明一种新的编程语言:-)

You can also take those SOLID principles too far. If you read Robert Martin's articles, he states that applying the principles across the board without any thought will yield overly complex code. Software is designed through a series of trade-offs and balancings - sometimes you forgo pure SOLID because it yields cleaner less complex code. If you were to make your code perfectly encapsulated, flexible, decoupled, etc., you will have invented a new programming language :-)

这篇关于复合图案是否牢固?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！