Alocarea unui model compozit
Utilizați modelul Compozit dacă:
- Este necesar să grupați și să gestionați grupuri de obiecte similare.
- Obiectele pot fi primitive (elementare) sau compuse (complexe). Un obiect compozit poate include colecții de alte obiecte, formând structuri complexe de arbori. Exemplu: Directorul sistemului de fișiere constă din elemente, fiecare dintre acestea putând fi și un director.
- Codul client funcționează uniform cu obiecte primitive și compuse.
Descrierea modelului compozit
Gestionarea grupurilor de obiecte poate fi o sarcină descurajantă, mai ales dacă aceste obiecte conțin obiecte proprii.
Pentru jocul strategic militar "Războaiele Punic", care descrie confruntarea militară dintre Roma și Cartagina (vezi secțiunea Generarea modelelor), fiecare unitate de luptă (călăreț, arcaș, infanterist) are propria forță distructivă. Aceste unități pot fi grupate pentru a forma unități militare mai complexe, de exemplu, legiunile romane, care, la rândul lor, se unesc între o armată întreagă. Cum se calculează puterea de luptă a unor astfel de conexiuni ierarhice?
Modelul compozit oferă următoarea soluție. Acesta introduce o componentă de bază abstractă de bază cu un comportament comun tuturor obiectelor primitive și compozite. În cazul unui joc strategic, aceasta este metoda getStrength () pentru a calcula forța distructivă. Subclasele Primitive și Composite sunt derivate din clasa Component. Obiectul compozit compus stochează componentele descendente ale componentei de tip abstract. fiecare dintre acestea putând fi de asemenea compozit.
Diagrama UML a claselor de tip compozit
Pentru a adăuga sau elimina obiecte copil într-un obiect compozit compozit. Clasa Component definește interfețele add () și remove ().
Implementarea modelului compozit
Aplicați modelul Compozit pentru jocul nostru de strategie. În primul rând, vom forma diferite unități militare ale armatei romane și apoi vom calcula forța distructivă.
Ar trebui să fim atenți la un punct important. Clasa abstractă de bază Unitatea declară o interfață pentru adăugarea de noi unități de addUnit (), chiar dacă nu este necesară pentru obiecte de tip primitiv (Archer.Infantryman.Horseman). Acest lucru este făcut pentru a satisface transparența sistemului în detrimentul securității acestuia. Clientul știe că un obiect de tip Unitate va avea întotdeauna metoda addUnit (). Cu toate acestea, apelul său la obiecte primitive este considerat a fi eronat și nesigur.
Puteți face sistemul mai sigur prin mutarea metodei addUnit () la obiectul CompositeUnit compozit. Cu toate acestea, apare următoarea problemă: nu știm dacă unitatea conține metoda addUnit ().
Luați în considerare următorul fragment de cod.
În unitatea abstractă de clasă de bază, o nouă metodă virtuală getComposite () cu o implementare implicită care returnează 0. Clasa CompositeUnit suprascrie această metodă, returnând pointerul la sine. Cu această metodă, puteți interoga componenta pentru tipul acesteia. Dacă este compusă, atunci puteți folosi operația addUnit ().
Rezultatele utilizării modelului compozit
Avantajele modelului compozit
- Este ușor să adăugați noi obiecte primitive sau compozite la sistem, deoarece modelul compozit folosește componenta comună de clasă de bază.
- Codul client are o structură simplă - obiectele primitive și complexe sunt manipulate în același mod.
- Modelul compozit facilitează ocolirea tuturor nodurilor unei structuri de copaci
Dezavantaje ale modelului compozit
- Este incomod să se interzică adăugarea anumitor tipuri de obiecte la un obiect compozit compozit. De exemplu, compoziția armatei romane nu poate include elefanți de luptă.
Articole similare
Trimiteți-le prietenilor: