Tem um - Has-a

Em design de banco de dados , programação orientada a objetos e design (ver arquitetura de programa orientada a objetos ), has-a ( has_a ou has a ) é um relacionamento de composição onde um objeto (frequentemente chamado de objeto constituído, ou objeto parte / constituinte / membro) " pertence a "(é parte ou membro de ) outro objeto (chamado de tipo composto) e se comporta de acordo com as regras de propriedade. Em palavras simples, o relacionamento has-a em um objeto é chamado de campo membro de um objeto. Vários relacionamentos tem-um se combinam para formar uma hierarquia possessiva.

Isso deve ser contrastado com uma relação is-a ( is_a or is a ) que constitui uma hierarquia taxonômica ( subtipagem ).

A decisão de se a relação mais lógica para um objeto e seu subordinado nem sempre é claramente has-a ou is-a . A confusão sobre tais decisões exigiu a criação desses termos metalinguísticos. Um bom exemplo do relacionamento tem-um são os contêineres no C ++ STL .

Para resumir as relações, temos

  • hiperonímia - hipônimo (supertipo-subtipo) as relações entre tipos (classes) que define uma hierarquia taxonómica, onde
    • para uma relação de herança : um hipônimo (subtipo, subclasse) tem uma relação tipo-de ( é-a ) com seu hiperônimo (supertipo, superclasse);
  • holônimo - relações meronímicas (todo / entidade / parte do contêiner / constituinte / membro) entre os tipos (classes) definindo uma hierarquia possessiva, onde
    • para uma relação de agregação (ou seja, sem propriedade):
      • um holônimo (todo) tem uma relação tem-uma com seu merônimo (parte),
    • para uma relação de composição (ou seja, com propriedade):
      • um merônimo (constituinte) tem uma relação parcial com seu holônimo (entidade),
    • para uma relação de contenção :
  • relações de objeto-conceito (token de tipo) entre tipos (classes) e objetos (instâncias), onde
    • um token (objeto) tem um relacionamento de instância com seu tipo (classe).

Exemplos

Modelo de entidade-relacionamento

Modelo de entidade-relacionamento

Em bancos de dados, os relacionamentos has-a são geralmente representados em um modelo de relacionamento de entidade . Como você pode ver pelo diagrama à direita, uma conta pode ter vários personagens. Isso mostra que a conta tem um relacionamento "tem um" com o personagem.

Diagrama de classe UML

Diagrama de classes UML
Maus usos de composição e agregação

Na programação orientada a objetos, esse relacionamento pode ser representado com um diagrama de Classes de Linguagem de Modelagem Unificada . Essa relação tem-um também é conhecida como composição. Como você pode ver no Diagrama de Classes à direita, um carro "tem" um carburador ou um carro "é composto" de um carburador. Quando o diamante é colorido de preto, significa composição , ou seja, o objeto do lado mais próximo do diamante é feito ou contém o outro objeto. Enquanto o diamante branco significa agregação , o que significa que o objeto mais próximo do diamante pode ter ou possuir o outro objeto.

C ++

Outra maneira de distinguir entre composição e agregação na modelagem do mundo real é considerar o tempo de vida relativo do objeto contido. Por exemplo, se um objeto Carro contiver um objeto Chassi, muito provavelmente um Chassi não será substituído durante a vida útil do Carro. Ele terá a mesma vida útil do próprio carro; portanto, a relação é de composição . Por outro lado, se o objeto Carro contiver um conjunto de objetos Pneu, esses objetos Pneu podem se desgastar e ser substituídos várias vezes. Ou se o carro ficar inutilizável, alguns pneus podem ser recuperados e atribuídos a outro carro. De qualquer forma, os objetos Tire têm vidas diferentes do que o objeto Carro; portanto, o relacionamento é de agregação .

Se alguém fosse fazer uma classe de software C ++ para implementar os relacionamentos descritos acima, o objeto Car conteria um objeto Chassis completo em um membro de dados. Este objeto Chassis seria instanciado no construtor da classe Car (ou definido como o tipo de dados do membro de dados e suas propriedades atribuídas no construtor). E como seria um membro de dados totalmente contido da classe Car, o Chassis objeto não existiria mais se um objeto da classe Carro fosse excluído.

Por outro lado, os membros de dados da classe Car que apontam para objetos Tire provavelmente seriam ponteiros C ++. Os objetos Tire podem ser instanciados e excluídos externamente, ou mesmo atribuídos a membros de dados de um objeto Car diferente. Os objetos Tire teriam um tempo de vida independente separado de quando o objeto Car foi excluído.

Veja também

Notas