Ha un - Has-a
Nella progettazione di database , programmazione e progettazione orientata agli oggetti (vedere architettura del programma orientata agli oggetti ), has-a ( has_a o has a ) è una relazione di composizione in cui un oggetto (spesso chiamato oggetto costituito, o parte / costituente / oggetto membro) " appartiene a "(è parte o membro di ) un altro oggetto (chiamato tipo composto) e si comporta secondo le regole di proprietà. In parole semplici, la relazione ha una relazione in un oggetto è chiamata campo membro di un oggetto. Molteplici relazioni has-a si combinano per formare una gerarchia possessiva.
Ciò deve essere contrastato con una relazione is-a ( is_a or is a ) che costituisce una gerarchia tassonomica ( sottotipizzazione ).
La decisione se la relazione più logica per un oggetto e il suo subordinato non è sempre chiaramente ha-a o è-a . La confusione su tali decisioni ha reso necessaria la creazione di questi termini metalinguistici. Un buon esempio della relazione has-a sono i contenitori in C ++ STL .
Per riassumere le relazioni, abbiamo
-
hypernym - relazioni iponime (supertipo-sottotipo) tra tipi (classi) che definiscono una gerarchia tassonomica, dove
- per una relazione di ereditarietà : un iponimo (sottotipo, sottoclasse) ha una relazione di tipo ( è-a ) con il suo ipernimo (supertipo, superclasse);
-
olonimo - relazioni meronimiche (intero / entità / parte-contenitore / costituente / membro) tra tipi (classi) che definiscono una gerarchia possessiva, dove
- per una relazione di aggregazione (cioè senza proprietà):
- un olonimo (intero) ha una relazione con il suo meronimo (parte),
- per una relazione di composizione (cioè con proprietà):
- un meronym (costituente) ha una parte-di relazione con il suo holonym (entità),
- per una relazione di contenimento :
- un meronimo (membro) ha una relazione di membro con il suo olonimo ( contenitore );
- per una relazione di aggregazione (cioè senza proprietà):
- relazioni concetto-oggetto (tipo-token) tra tipi (classi) e oggetti (istanze), dove
- un token (oggetto) ha una relazione di istanza con il suo tipo (classe).
Esempi
Modello entità-relazione
Nei database le relazioni has-a sono generalmente rappresentate in un modello Entità-relazione . Come puoi vedere dal diagramma a destra, un account può avere più caratteri. Questo dimostra che l'account ha una relazione "ha-a" con il personaggio.
Diagramma delle classi UML
Nella programmazione orientata agli oggetti questa relazione può essere rappresentata con un diagramma di classe Unified Modeling Language . Questa relazione è nota anche come composizione. Come puoi vedere dal diagramma delle classi a destra un'auto "ha-un" carburatore , oppure un'auto è "composta" da un carburatore. Quando il diamante è di colore nero significa composizione , cioè l'oggetto sul lato più vicino al diamante è costituito o contiene l'altro oggetto. Mentre il diamante bianco significa aggregazione , il che significa che l'oggetto più vicino al diamante può avere o possedere l'altro oggetto.
C ++
Un altro modo per distinguere tra composizione e aggregazione nella modellazione del mondo reale è considerare la durata relativa dell'oggetto contenuto. Ad esempio, se un oggetto Auto contiene un oggetto Chassis, molto probabilmente non verrà sostituito durante il ciclo di vita dell'auto. Avrà la stessa durata dell'auto stessa; quindi il rapporto è di composizione . D'altra parte, se l'oggetto Auto contiene un set di oggetti Tyre, questi oggetti Tyre potrebbero usurarsi e essere sostituiti più volte. Oppure, se l'Auto diventa inutilizzabile, alcuni Pneumatici possono essere recuperati e assegnati a un'altra Auto. In ogni caso, gli oggetti Tyre hanno durate diverse rispetto all'oggetto Auto; quindi la relazione è di aggregazione .
Se si dovesse creare una classe software C ++ per implementare le relazioni descritte sopra, l'oggetto Car conterrebbe un oggetto Chassis completo in un membro dati. Questo oggetto Chassis verrebbe istanziato nel costruttore della classe Car (o definito come il tipo di dati del membro dati e le sue proprietà assegnate nel costruttore). E poiché sarebbe un membro dati interamente contenuto della classe Car, il Chassis oggetto non esisterebbe più se un oggetto della classe Car dovesse essere cancellato.
D'altra parte, i membri dei dati della classe Car che puntano a oggetti Tyre sarebbero molto probabilmente puntatori C ++. Gli oggetti Tyre possono essere istanziati ed eliminati esternamente o persino assegnati a membri di dati di un oggetto Car diverso. Gli oggetti Tyre avrebbero una durata indipendente separata da quando l'oggetto Car è stato eliminato.
