Notações de diagrama de classe UML: diferenças entre associação, agregação e composição

Estou confuso sobre algumas das notações dos diagramas de classes UML.

Tenho certeza que sei o que significa Associação . Qualquer relacionamento entre instâncias de duas classes, em que uma instância de uma classe precisa saber sobre uma instância da segunda classe para executar seu trabalho - é um relacionamento de Associação. Uma associação geralmente significa que a classe A tem uma referência (campo) a uma instância da classe B.

No entanto, estou tendo problemas para entender o que significam as setas de agregação e composição . Parte da minha confusão foi causada por encontrar diferentes definições dessas notações.

Duas definições da notação de agregação :

Definição 1: Uma notação de agregação entre duas classes é adequada sempre que uma instância da classe A contém uma coleção de instâncias da classe B (por exemplo, uma lista, matriz, o que for).

Definição 2: Um link de agregação entre duas classes é adequado se uma instância da classe A tiver uma referência a uma instância da classe B e a instância B depender do ciclo de vida da instância A. Significado: Quando a instância da classe A é excluída, a instância da classe B. também é a instância da classe B. A instância da classe B é totalmente contida pela instância da classe A, em oposição à instância da classe A, simplesmente possuindo uma referência à instância de classe B (que é uma associação regular).

Quanto ao significado da notação Composition e como ela difere da notação Aggregation, não tenho certeza.

Por favor, esclareça as definições e me ajude a entender. Exemplos concretos seriam bem-vindos.

Os três links Associação, Agregação e Composição formam uma espécie de escala sobre a proximidade entre duas classes.

Por um lado da escala, há Associação, onde objetos das duas classes podem se conhecer, mas não afetam a vida de cada um. Os objetos podem existir independentemente e qual objeto de classe A sabe sobre quais objetos de classe B podem variar ao longo do tempo.

No outro extremo da escala, há Composition. A composição representa um relacionamento parte-todo, de modo que a classe B é parte integrante da classe A. Esse relacionamento é normalmente usado se objetos da classe A não puderem existir logicamente sem ter um objeto da classe B.

A relação de agregação está em algum lugar entre esses dois fins, mas parece que ninguém concorda exatamente onde, portanto, também não há uma definição universalmente aceita do que significa uma agregação. Nesse sentido, as duas definições encontradas são corretas e, se você perguntar a 10 pessoas, corre o risco de obter 11 definições diferentes.

Composição é quando um object Acontém object Be object Atambém é responsável pela criação do object B.

Relação de composição

Temos uma classe A que será usada pela classe B.

final class A
{
}

Existem várias opções para a aparência da composição.

Composição de inicialização direta:

final class B
{
    private $a = new A();
}

Composição de inicialização do construtor

final class B
{
    private $a;

    public function __construct()
    {
        $this->a = new A();
    }
}

Composição de inicialização lenta

final class B
{
    private $a = null;

    public function useA()
    {
        if ($this->a === null) {
            $this->a = new A();
        }

        /* Use $this->a */
    }
}

Você vê que isso cria uma relação estreita entre as classes Ae B. A classe Bsimplesmente não pode existir sem A. Essa é uma violação enorme do princípio de injeção de dependência , que diz:

Uma dependência é um objeto que pode ser usado (um serviço). Uma injeção é a passagem de uma dependência para um objeto dependente (um cliente) que a usaria. O serviço faz parte do estado do cliente. Passar o serviço para o cliente, em vez de permitir que um cliente construa ou localize o serviço, é o requisito fundamental do padrão.

Às vezes, a composição faz sentido, como chamar new DateTimephp ou new std::vector<int>C ++. Mas, na maioria das vezes, é um aviso que seu design de código está errado.

Em um caso, onde class Aseria um objeto especial usado para armazenar em cache, class Bele sempre seria armazenado em cache usando a implementação de class Ae você não teria controle para alterá-lo dinamicamente, o que é ruim.

Além disso, se você usasse a composição de inicialização lenta , o que significa que você teria um trabalho object B, chamado useA()método e a criação de object Afalhas, seu object Brecurso será subitamente inútil.

A agregação, por outro lado, é um modo de relacionamento, que segue o princípio da DI . object Bprecisa usar object A, você deve passar a instância já criada de object Apara object Be, se a criação de object Afalha, nada será passado em primeiro lugar.

Em resumo, a agregação é uma representação UML para o princípio de injeção de dependência , seja injeção de construtor, injeção de setter ou injeção de propriedade pública.

Estas são todas as agregações

A injeção mais apertada do construtor ( object Bnão pode existir sem object A).

final class B
{
    private $a;

    public function __construct(A $a)
    {
        $this->a = $a;
    }
}

Mais frouxo (você pode ou não usar object Adentro object B, mas se o fizer, provavelmente deverá defini-lo primeiro).

Via setter:

final class B
{
    private $a;

    public function setA(A $a)
    {
        $this->a = $a;
    }
}

Via propriedade pública:

final class B
{
    public $a;
}

Não há realmente uma ótima maneira de justificar o uso de Agregação sobre composição, se tudo o que você está usando são implementações concretas de classes, mas quando você começa a injetar interfaces ou no caso de classes abstratas C ++, de repente a Agregação será a única maneira de cumprir seu contrato.

Além disso, um trecho do atual padrão UML:

11.5.4 Associações - Semântica - Notação

[...] Uma associação binária pode ter uma extremidade com agregação = AggregationKind :: shared ou agregation = AggregationKind :: composite. Quando uma extremidade possui agregação = AggregationKind :: shared, um diamante oco é adicionado como um adorno terminal no final da linha Association, do lado oposto ao final marcado com agregation = AggregationKind :: shared. O diamante deve ser visivelmente menor que a notação de diamante para as Associações. Uma associação com agregação = AggregationKind :: composite também possui um diamante no final correspondente, mas difere em ter o diamante preenchido . […]

9.5.4 Classificação - Propriedades - Notação

[…] Às vezes, uma propriedade é usada para modelar circunstâncias nas quais uma instância é usada para agrupar um conjunto de instâncias; isso é chamado de agregação. Para representar tais circunstâncias, uma Propriedade tem uma propriedade de agregação, do tipo AggregationKind; a instância que representa o grupo inteiro é classificada pelo proprietário da Propriedade e as instâncias que representam os indivíduos agrupados são classificadas pelo tipo da Propriedade. AggregationKind é uma enumeração com os seguintes valores literais:

• none : indica que a propriedade não possui semântica de agregação.
• Compartilhado : indica que a propriedade possui semântica de agregação compartilhada. A semântica precisa da agregação compartilhada varia de acordo com a área de aplicação e o modelador.
• Composto : Indica que a Propriedade é agregada de maneira composta, ou seja, o objeto composto é responsável pela existência e armazenamento dos objetos compostos (consulte a definição de partes em 11.2.3). A agregação composta é uma forma forte de agregação que requer que um objeto de peça seja incluído no máximo em um objeto composto de cada vez. Se um objeto composto for excluído, todas as suas instâncias de peça que são objetos serão excluídas.

[...]

Eu já postei uma resposta no Stackoverflow .

Basicamente, uma agregação é mais forte que uma associação simples, mas os objetos agregados podem continuar "vivendo" um sem o outro, como acontece com uma associação simples.

Uma composição é ainda mais forte que uma agregação porque a classe agregada não pode ser agregada por outras classes. Sua "vida" depende do recipiente.