A cosa serve l'associazione, l'aggregazione e la composizione?

La distinzione tra associazione, aggregazione e composizione così come la descrivi è un'eredità che risale ai vecchi tempi della gestione manuale della memoria. Ad esempio in C ++ la memoria utilizzata dagli oggetti deve essere rilasciata manualmente ed è quindi fondamentale progettare attentamente il ciclo di vita degli oggetti composti. Mentre la distinzione tra aggregazione e composizione viene ancora insegnata da molti libri di testo, è sostanzialmente irrilevante quando si programma in ambienti con gestione automatica della memoria. Se si dispone di garbage collection, tutti sono solo composizione, punto.

L'incapsulamento d'altra parte è un principio molto più generale di quello che descrivi. È soprattutto l'idea di raggruppare i dati e le funzioni che operano su questi dati in un modulo. Un modo per implementare questo è mantenere lo stato del modulo privato ed esporre le modifiche a quello stato attraverso i servizi pubblici. Quindi il client non può accedere allo stato da solo, ma deve comunicare al modulo la propria intenzione inviando messaggi. Quindi l'incapsulamento non è limitato agli oggetti ma si applica anche ai servizi. In realtà, un modo di guardare gli oggetti è considerarli come servizi.

Ecco un esempio di incapsulamento

public class Counter {
    private int n = 0;
    public int inc() { return n++; }
}

o lo stesso usando le funzioni lambda

var counter = (function() {
    var n = 0;
    var inc = function() { return n++; }
    return inc;
})();

In entrambi i casi i dati, ovvero la variabile n , sono raggruppati insieme alla funzione inc che opera su di essa. E non c'è modo che nessuna altra funzione possa mai accedere a n , quindi abbiamo un modulo incapsulato che fornisce il conteggio come servizio.

NB: esporre tutto lo stato interno di un oggetto tramite gli accessor è in realtà una violazione dell'incapsulamento. Ahimè, è una violazione così comune che molti lo confonderanno con un buon design orientato agli oggetti.

L'incapsulamento è la tecnica per rendere privati i campi di una classe e fornire l'accesso ai campi tramite metodi pubblici. Se un campo è dichiarato privato, non è accessibile a nessuno al di fuori della classe, nascondendo quindi i campi all'interno della classe. Per questo motivo, l'incapsulamento viene anche definito come occultamento dei dati.

    public class Test{

    private String name;

       private int age;

       public int getAge(){
          return age;
       }

       public String getName(){
          return name;
       }
    }

Riferisci questa domanda anche .

Associazione indica la relazione tra gli oggetti. Ad esempio: il computer utilizza la tastiera come dispositivo di input.

Un'associazione viene utilizzata quando un oggetto desidera che un altro oggetto esegua un servizio per esso.

Aggregation è un caso speciale di associazione. Un'associazione direzionale tra oggetti. Quando un oggetto "ha-un" un altro oggetto, allora hai un'aggregazione tra di loro.

Es: Room ha una tabella, ma la tabella può esistere senza la stanza.

    class Room {

      private Table table;

      void setTable(Table table) {
        this.table = table;
      }

    }

Composition è un caso speciale di aggregazione. La composizione è più restrittiva. Quando c'è una composizione tra due oggetti, l'oggetto composto non può esistere senza l'altro oggetto. Questa restrizione non è presente in aggregazione. ad esempio: stanze in una casa, che non possono esistere dopo la vita della casa.

    class House {

      private  Room room;

      House(Room roomSpecs) {
        room = new Room(roomSpecs);
      }

    }

La composizione è una tecnica di progettazione per implementare la relazione has-a nelle classi, per Ereditarietà o Composizione di oggetti per il riutilizzo del codice.

Una delle migliori pratiche nella programmazione Java consiste nell'usare la composizione sull'ereditarietà

L'utilizzo di tali tecniche di solito comporta pratiche di progettazione come SOLID o vari pattern di design .

Il punto di usare schemi, pratiche e tali è descrivere una soluzione a un problema specifico che è anche mantenibile ed estensibile. Devi semplicemente avere abbastanza esperienza per dire dove usare quale modello o tecnica.

Sinceramente sento che queste nozioni insegnate in ambito accademico hanno la loro importanza nei contesti di orientamento agli oggetti e design di classe. Questi concetti ci aiutano molto quando si tratta di modellare un sistema da zero. Associazione, aggregazione e composizione appartengono esclusivamente al diagramma di classe di UML e sono completamente indipendenti da vincoli di tecnologia come problemi di memoria.

Inoltre, devi anche considerare il livello più alto o gli obiettivi di business del sistema che stai modellando. Abbiamo oggetti come House e Room nel nostro sistema in esame, ma non possiamo essere strongmente correlati (tramite la composizione). Per esempio, se sto modellando un sistema immobiliare, dovrei sapere quale camera appartiene a quale casa. Ma lascia che modifico un sistema di rilevamento o di censimento in cui voglio sapere quante persone vivono in ogni stanza della casa in una certa area, quindi non ho bisogno di mettere in relazione una stanza con una casa tramite la composizione.

Un altro esempio potrebbe essere un frutteto e un certo tipo di frutta. Diciamo che posso considerare un frutteto solo quando ho alberi di mele piantati al suo interno. La linea di fondo è che i requisiti dell'intero sistema sono molto importanti.

L'incapsulamento è uno dei pilastri del design orientato agli oggetti. Devi raggruppare i tuoi dati e le operazioni che eseguirai sui tuoi dati. inoltre devi nascondere alcuni attributi del tuo oggetto dal mondo esterno per consentire a quell'oggetto di sopravvivere in uno stato valido. Quando 2 oggetti interagiscono, devono interagire l'un l'altro tramite un'interfaccia. E questo è ciò che garantisce l'incapsulamento quando progettiamo il nostro sistema OO.

Ecco come vengono applicati questi concetti al codice:

ASSOCIATION: Association indica la relazione tra gli oggetti. Permette al programmatore di sapere quali metodi scrivere nelle proprie classi per farli interagire tra loro. Puoi trovare diversi esempi di diagrammi di codice e classe per capire l'associazione. Nel tuo esempio di Insegnante e Studente, esiste una relazione di insegnamento e insegnata da . Quindi dovrai semplicemente scrivere una serie di metodi (tecnicamente chiamati interfaccia) tramite i quali puoi conoscere quale studente ha ciò che gli insegnanti e quale insegnante ha quali studenti. L'associazione consente inoltre al modellatore di sistema di aiutare il progettista del database sugli attributi e i campi che devono essere conservati nel database.

COMPOSIZIONE: Se un oggetto è parte integrante di un altro oggetto, allora potrei dover indicare questa relazione nel costruttore dell'altro oggetto. Ad esempio, nel tuo scenario di Case e Stanze possiamo scrivere il seguente codice nel caso in cui desideriamo sapere quale camera appartiene a quale tipo di casa.

class House{
          string _HouseType;   
     public:    
    void setHouseType(string house_type)
     {
        this. _HouseType = house_type;
     } 

     string getHouseType()
    {
       return _HouseType;
    }
};



 House HouseObject = new House();


class Room{

 public: 
 Room(string HouseType) {
       this._HouseType = HouseObject.getHouseType();  //as in my system a room cannot exist without a house

 } 

};

Il programmatore si assicurerà anche durante l'invocazione di destructors dell'oggetto, che viene anche richiamato il destuctor dell'altro oggetto. Questo è fondamentale.

AGGREGAZIONE: Diciamo che se la relazione tra gli oggetti è debole allora per il programmatore, significherebbe usare invece una variabile di istanza per indicare la relazione. E poi scrivi un functon mutatore (setter) per fornire valore a quell'oggetto da un altro.

class Department{

 string dept_name;

public:
   void setDeptName(string name)
   {
        this.dept_name=name;
   }

   string getDeptName()
   {
        return dept_name; 
   }

};



 Department DepartmentObject = new Department();

class Teacher{

 string dept_name;

public:

  setDeptName(string name)
  {
     this.dept_name = DepartmentObject.getDeptName();  //You only need to invoje this method when needed (aggregation)
  }
}

};

OK, mappiamolo su alcune proprietà chiave piuttosto che su concetti astratti che hanno senso solo quando capisci cosa significano. Come alcuni commentatori, non sono d'accordo con la risposta accettata, dico che sono concetti indipendenti dalla gestione della memoria.

incapsulamento

Vuoi nascondere la complessità dal client, solo pubblicando le cose che contano dal punto di vista del cliente, rendendo le cose più facili per il cliente. Come bonus ottieni la certezza che nulla può rovinare il codice incapsulato. Finché rispetti l'interfaccia e la funzionalità, puoi rielaborare le cose e ti assicuro che non rompere nulla. La dipendenza è solo sull'interfaccia pubblicata.

L'incapsulamento è uno dei pilastri principali dell'orientamento agli oggetti. Non è un modello, è un principio e può essere applicato alla logica e ai dati allo stesso modo. È solo un vantaggio fondamentale dell'uso delle classi in primo luogo, non di qualcosa che vedresti esplicitamente in un diagramma o in un documento di progettazione.

Associazione

Questo è un concetto molto sciolto che fondamentalmente descrive solo una dipendenza tra oggetti. Un oggetto conosce l'esistenza di un altro oggetto e può utilizzare la sua funzionalità a un certo punto. In un diagramma l'associazione ti avvisa che esiste una dipendenza e che la modifica di un oggetto può avere un impatto sull'altro. Non è una tecnica da applicare quando hai qualche problema da risolvere, è più come un fatto della vita dovresti essere consapevole di quando è lì. È una relazione. Come una fattura con una proprietà Ordini. Sia l'ordine sia la fattura hanno il loro ciclo di vita. Uno riguarda i beni e l'altro riguarda il pagamento, il che li rende essenzialmente indipendenti, ma è importante sapere per quali merci vengono pagati.

Contenimento

Sto aggiungendo questo perché appartiene alla serie e renderà l'aggregazione più significativa. Non sento più il termine usato in un contesto SE, ma penso che sia ancora utile. Il contenimento implica l'incapsulamento ma è strettamente relativo alle istanze dell'oggetto private della classe contenente. La funzionalità degli oggetti contenuti è esposta selettivamente tramite interfacce pubbliche. La classe contenente controlla il ciclo di vita degli oggetti controllati. Lo usi quando hai bisogno di alcune funzionalità di una classe esistente per rendere funzionale la classe contenente. Potrebbe trattarsi di un parser XML e il client della classe contenente potrebbe non vedere mai o sapere nulla relativo a XML. Come metafora, pensa all'oggetto contenuto come un back office worker. I clienti non incontrano mai queste persone ma sono necessarie per fornire il servizio.

Aggregazione

Questo è molto simile al contenimento ad eccezione del controllo del ciclo di vita e della visibilità degli oggetti aggregati. Gli oggetti aggregati sono già disponibili in un contesto diverso e sono gestiti da una diversa entità. L'aggregatore offre semplicemente una facciata, un portale per gli oggetti aggregati. Quando il client si rivolge all'aggregato, ottiene l'interfaccia dell'oggetto stesso, non un involucro attorno ad esso. Il punto dell'aggregazione sta offrendo un raggruppamento logico di cose. Pensa a un punto di accesso ai servizi o ad altri oggetti wrapper.

Composizione

Mi sembra questo il termine più moderno per il contenimento, forse perché è stato coniato in un libro popolare di origine relativamente recente. Laddove il contenimento si concentra sugli aspetti tecnici delle relazioni oggettuali, la composizione viene tipicamente utilizzata nel contesto delle decisioni progettuali, in particolare come alternativa più flessibile per l'ereditarietà.

Non dice molto sulla natura delle relazioni o della proprietà degli oggetti, indica semplicemente che la funzionalità è implementata combinando la funzionalità delle classi esistenti. Quindi direi che non appartiene a questa serie perché non dice nulla sugli aspetti tecnici di un'implementazione in cui gli altri fanno.