oop - 桥接模式——组合还是聚合？

Question

我正在阅读一些有关设计模式的书籍，有些将抽象和实现之间的关系描述为组合，有些则将其描述为聚合。现在我想知道:这取决于实现吗？就语言而言？或者上下文？

Answer 1

术语“组合物”和“聚集”的含义或多或少相同，并且可以互换使用。在描述容器类(例如列表、动态数组、映射和队列)时，聚合可能会更频繁地使用，其中元素都属于同一类型；然而，这两个术语都可以描述根据其他类定义的类，无论这些类型是同质的(全部相同类型)还是异质的(不同类型的对象)。

为了更清楚地说明这一点:

class Car {
    // ...
    private:
        Engine engine;
        Hood hood;
};

// The car is *composed* of an engine and a hood. Hence, composition. You are
// also bringing together (i.e. *aggregating*) an engine and hood into a car.

抽象和实现之间的关系通常意味着继承，而不是组合/聚合；通常，抽象是接口(interface)或虚拟基类，实现是实现给定接口(interface)的完全具体的类。但是，让事情变得困惑的是，组合/聚合可以是接口(interface)的一部分(因为，例如，您可能需要设置/获取用作构建 block 的对象)，并且它们也是一种实现方法(因为您可以使用委托(delegate)来提供实现中方法的定义)。

为了更清楚地说明这一点:

interface Car {
    public Engine getEngine();
    public Hood getHood();
    public void drive();
}
// In the above, the fact that a car has these building blocks
// is a part of its interface (the abstraction).

class HondaCivic2010 implements Car {
    public void drive(){ getEngine().drive(); }
    // ...
}
// In the above, composition/delegation is an implementation
// strategy for providing the drive functionality.

既然您已将问题标记为“桥”，我应该指出，桥模式的定义是一种使用组合而不是继承来允许多个不同级别的变化的模式。我在大学学到的一个例子......使用继承你可能会得到类似的东西:

class GoodCharacter;
class BadCharacter;
class Mage;
class Rogue;
class GoodMage : public GoodCharacter, Mage;
class BadMage : public BadCharacter, Mage;
class GoodRogue : public GoodCharacter, Rogue;
class BadRogue : public BadCharacter, Rogue;

正如你所看到的，这种事情变得非常疯狂，你得到的类数量多得荒唐。同样的事情，使用桥接模式，看起来像:

 class Personality;
 class GoodPersonality : public Personality;
 class BadPersonality : public Personality;

 class CharacterClass;
 class Mage : public CharacterClass;
 class Rogue : public CharacterClass;

 class Character {
    public:
        // ...
    private:
        CharacterClass character_class;
        Personality personality;
 };
 // A character has both a character class and a personality.
 // This is a perfect example of the bridge pattern, and we've
 // reduced MxN classes into a mere M+N classes, and we've
 // arguably made the system even more flexible than before.