构图（又名关联）是如何实现重用的另一种方式？

Question

另一个对象内部的对象和第一个对象如何重新使用组合对象背后的代码在运行时可以确定组合对象的含义是什么？

class Calculator 
{ 
    private: 
     long double operand_1; 
     long double operand_2; 
     long double result; 
     int optr; 
     int multiplier; 
     Button One; 
     //Button Two.. 
     //..through Nine 
     Button Zero; 
} 

class Button 
{ 
    private: 
     int x1; 
     int y1; 
     int x2; 
     int y2; 
     char Label[55]; 

    public: 
     Button(); 
     int hit(); 
     void show(); 
     void press(); 
     void select(); 
} 

我不知道我是否要去的方向是正确与否，我想知道的“组成的对象可以在运行时决定？” 这里按钮组成的含义在计算器类中

Answer 1

此原则在Effective Java Book中显示为'Item 16'。我认为，当它被称为“赞成构造而不是继承来重用代码”时，'构造'这个词被用作'Containment'或'association'的同义词，而不是UML真实构成的精神。 Joshua Bloch的“Effective Java”在“Item 16”中提供了很好的例子。

在上面这本书的演示示例中，containment（Set的子类）实例通过构造函数传递，并且总是可以缓存在外面（由客户端）中断构图。在书的演示中，它也是遏制的情况，而不是纯粹的组合（其中组合对象在外面是不知道的）。

代码重用可以通过两种机制实现，即'继承（白盒）'和'包容（黑盒）'。在黑盒重用的情况下，我们可以在运行时通过为抽象基类/接口的引用分配一个子类的实例来耦合可重用类。原则上，只有在存在'IsA'关系时才应使用继承，并且我们希望使用对象可交换性并获得多态行为的优势。

在你的例子中，虽然计算器正在使用按钮，它不期待动态子类实例。但是当我们说addActionListener（）时，Button类将通过Containment使用ActionListener作为'Button不是一种ActionListener'，而是Button'使用'ActionListener。

这是一个由Composition复用的例子。那个List的实例在PackOfCards之外是不知道的，但是PackOfCards内部正在将所有功能委托给具体列表，当PackOfCards的Object被销毁时，List也被销毁，但是这里我们不能动态地改变具体List

public class Card { 
    public enum Suit{SPADE, HEART,DIAMOND,CLUB} 
    public enum Rank{ACE,QUEEN,KING}// and others 
    private Suit suit; 
    private Rank rank; 
    public Card(Suit suit, Rank rank) { 
     this.suit = suit; 
     this.rank = rank; 
    } 
} 
public class PackOfCards { 
    private List<Card> cards; 

    public PackOfCards() { 
     cards = new LinkedList<Card>(); 
    } 

    public Card getCard(int index){ 
     return cards.get(index); 
    } 

    public void shuffle(){ 
     Collections.shuffle(cards); 
    } 
    // other methods 
}