Întregul este mai mare decât suma părților sale
-Aristotel
Acest citat este atribuit lui Aristotel. Ideea de bază este una de sinergie. În cartea de succes a lui Stephen Covey, The 7 Habits of Highly Effective People (Cele 7 obiceiuri ale oamenilor foarte eficienți), al șaselea obicei este Sinergizarea. Ceea ce este valabil în cazul organizațiilor este valabil și în domeniul informaticii. Corpul unui obiect este mai valoros decât individul său. În informatică, folosim termenul de compoziție.
Compoziție
Atunci ce înțelegem prin compoziție? „Compoziția este unul dintre conceptele fundamentale în programarea orientată pe obiecte. El descrie o clasă care face referire la unul sau mai multe obiecte ale altor clase în variabile de instanță. Acest lucru vă permite să modelați o asociere de tip „has-a” între obiecte.” Iată cum o descrie Stackify aici. Gândiți-vă la ea ca la o orchestră. Un singur interpret este drăguț, dar atunci când aveți întregul grup împreună, muzica este mai bogată și mai profundă.
Beneficii
Principalul beneficiu pentru codul creat cu o compoziție adecvată este reutilizarea. Dacă îl proiectezi corect, ar trebui să fie ușor de reutilizat. Dacă nu, atunci poate fi destul de greoi. Împreună cu aceasta este o API sau o interfață de programare a aplicațiilor intuitivă și curată. În calitate de programator Java cu experiență, am auzit numeroase persoane deplângând designul API-ului de threading al Java. Un design bun ar trebui să vă permită să modificați ceva intern și să nu schimbați modul în care alții interacționează cu acesta.
Exemple
Să creăm un exemplu pentru a vedea cum arată compoziția în Java.
Aici avem definită clasa noastră Role.
Clasa Role este utilizată în această clasă Employee. În compoziție, ați spune că clasa Angajat „are un” Rol.
Hiding
În exemplul nostru de API, clasele HotDogGrinder și HotDogGrill sunt package-private și nu pot fi accesate din exterior.
Iată fața publică a API-ului nostru, HotDogMachine. Această clasă are o referință la cele două clase interne pe care le ascundem prin proiectarea API-ului nostru.
Compoziție vs Moștenire
Compoziția și moștenirea pot fi confundate de către dezvoltatori. După cum subliniază Steven Lowe în această postare pe blogul ThoughtWorks, trebuie să alegem cu atenție pe care să o folosim.
El împărtășește regula de bază des auzită, „favorizează compoziția în detrimentul moștenirii”. Ca în cazul oricărei reguli generale, trebuie să înțelegem că nu se aplică întotdeauna. Așa că haideți să punem câteva lucruri la punct înainte de a merge mai departe.
Să definim moștenirea, deoarece am vorbit deja pe larg despre compoziție. Moștenirea este una dintre bazele programării orientate pe obiecte. De exemplu, dacă avem o clasă mâncare, atunci clasa pâine va moșteni din clasa mâncare. În timp ce compoziția se ocupă de elementele care fac parte dintr-o unitate mai mare.
Lowe ne reamintește că atunci când ați putea folosi oricare dintre ele trebuie să ne punem două întrebări diferite. Prima: „Reprezentarea/implementarea conceptelor domeniului tău este o dimensiune”. În esență, dacă ambele sunt în același domeniu, moștenirea este probabil cea mai bună opțiune. În al doilea rând, „Semantica conceptelor domeniului dvs. și relația dintre ele este o a doua dimensiune”. Componentele pe care le creați încep să se redirecționeze către o alta acest lucru ar putea fi un semn că ar trebui să reconsiderați utilizarea moștenirii în schimb.
Compoziția este un principiu important în dezvoltarea de software pe care mulți dintre noi, profesioniștii, îl încurcă. Eu însumi am făcut acest lucru deoarece am creat soluții neabordându-l corect. O discuție rapidă pe tablă cu un coleg sau schițarea a ceva pe o bucată de hârtie vă poate ajuta să înțelegeți când există o relație „has-a” între două obiecte. După ce ați citit acest lucru, ar trebui să înțelegeți, de asemenea, beneficiile și să știți cum să o utilizați într-un exemplu. Încercați să construiți un exemplu și să îl folosiți, apoi ar trebui să știți dacă sunteți pe drumul cel bun sau poate că moștenirea ar putea fi o cale mai bună.
.