Il tutto è più grande della somma delle sue parti
-Aristotele
Questa citazione è attribuita ad Aristotele. Il punto fondamentale è quello della sinergia. Nel libro best-seller di Stephen Covey, The 7 Habits of Highly Effective People, la sesta abitudine è sinergizzare. Ciò che è vero con le organizzazioni è vero anche nell’informatica. Il corpo di un oggetto è più prezioso del suo individuo. In informatica, usiamo il termine composizione.
Composizione
Cosa intendiamo per composizione? “La composizione è uno dei concetti fondamentali nella programmazione orientata agli oggetti. Descrive una classe che fa riferimento a uno o più oggetti di altre classi nelle variabili di istanza. Questo permette di modellare un’associazione has-a tra oggetti”. Questo è il modo in cui Stackify lo descrive qui. Pensatelo come un’orchestra. Un esecutore è bello, ma quando hai tutto il gruppo insieme la musica è più ricca e profonda.
Benefici
Il vantaggio principale per il codice creato con una composizione corretta è il riutilizzo. Se lo si progetta correttamente dovrebbe essere facile da riutilizzare. Altrimenti può essere piuttosto ingombrante. Insieme a questo è un’API o Application Programming Interface intuitiva e pulita. Come programmatore Java esperto, ho sentito numerose persone lamentarsi del design delle API di threading di Java. Un buon design dovrebbe permetterti di cambiare qualcosa internamente e non cambiare come gli altri interagiscono con esso.
Esempi
Creiamo un esempio così possiamo vedere come appare la composizione in Java.
Qui abbiamo definito la nostra classe Role.
La classe Role è usata in questa classe Employee. Nella composizione, si direbbe che la classe Employee “has-a” Role.
Hiding
Nel nostro esempio di API, le classi HotDogGrinder e HotDogGrill sono package-private e non sono accessibili dall’esterno.
Ecco la faccia pubblica della nostra API, HotDogMachine. Questa classe ha un riferimento alle due classi interne che stiamo nascondendo con il nostro design API.
Composizione vs Ereditarietà
Composizione ed ereditarietà possono essere confuse dagli sviluppatori. Come Steven Lowe sottolinea in questo post sul blog di ThoughtWorks, dobbiamo scegliere attentamente quale usare.
Condivide la regola empirica spesso sentita, “favorire la composizione sull’ereditarietà”. Come ogni regola empirica, dobbiamo capire che non si applica sempre. Quindi chiariamo alcune cose prima di andare avanti.
Definiamo l’ereditarietà dato che abbiamo già parlato a lungo della composizione. L’ereditarietà è uno dei fondamenti della programmazione orientata agli oggetti. Per esempio, se abbiamo una classe cibo, la classe pane erediterà dalla classe cibo. Dove la composizione si occupa di elementi che fanno parte di un’unità più grande.
Lowe ci ricorda che quando si potrebbe usare l’uno o l’altro abbiamo bisogno di fare due domande diverse. In primo luogo, “La rappresentazione/implementazione dei vostri concetti di dominio è una dimensione”. Essenzialmente se entrambi sono nello stesso dominio l’ereditarietà è probabilmente la vostra migliore scommessa. In secondo luogo, “La semantica dei vostri concetti di dominio e la loro relazione reciproca è una seconda dimensione”. I componenti che crei iniziano ad inoltrare ad un altro questo potrebbe essere un segno che potresti aver bisogno di riconsiderare l’uso dell’ereditarietà invece.
La composizione è un grande principio nello sviluppo del software che molti di noi professionisti pasticciano. L’ho fatto io stesso quando ho creato soluzioni non approcciate correttamente. Una rapida discussione alla lavagna con un collega o abbozzare qualcosa su un pezzo di carta può aiutare a capire quando c’è una relazione “has-a” tra due oggetti. Dopo aver letto questo dovreste anche capire i vantaggi e sapere come usarlo in un esempio. Provate a costruire qualche esempio e usatelo, poi dovreste sapere se siete sulla strada giusta o se l’ereditarietà potrebbe essere un percorso migliore.