Până acum, în această serie, am discutat despre programarea orientată pe obiecte în general și despre principiul PPE al coeziunii. În acest articol, vom examina principiul cuplare și cum ajută la dezvoltarea jocului.
Notă: Deși acest tutorial este scris folosind Java, ar trebui să puteți folosi aceleași tehnici și concepte în aproape orice mediu de dezvoltare a jocului.
Cuplarea este principiul "separării preocupărilor". Aceasta înseamnă că un obiect nu modifică sau modifică în mod direct starea sau comportamentul unui alt obiect.
Cuplarea privește relația dintre obiecte și cât de strâns sunt acestea. O diagramă de relații este o modalitate excelentă de a vizualiza conexiunile dintre obiecte. Într-o astfel de diagramă, casetele reprezintă obiecte și săgețile reprezintă o conexiune între două obiecte în care un obiect poate afecta în mod direct un alt obiect.
Un bun exemplu de cuplare este HTML și CSS. Înainte de CSS, HTML a fost folosit atât pentru marcare, cât și pentru prezentare. Acest lucru a creat un cod inflamat care a fost greu de schimbat și dificil de întreținut. Odată cu apariția CSS, HTML a fost folosit doar pentru marcare, iar CSS a preluat pentru prezentare. Acest lucru a făcut codul destul de curat și ușor de schimbat. Preocupările legate de prezentare și marcare au fost separate.
Obiectele care sunt independente unele de altele și nu modifică direct starea altor obiecte sunt considerate a fi slab cuplate. Combinarea loose permite codului să fie mai flexibil, mai flexibil și mai ușor de utilizat.
Obiectele care se bazează pe alte obiecte și care pot modifica stările altor obiecte sunt considerate a fi strans cuplate. Conectarea strânsă creează situații în care modificarea codului unui obiect necesită, de asemenea, schimbarea codului altor obiecte (cunoscut și ca efect de ripple). Codul cuplat strâns este, de asemenea, mai greu de reutilizat deoarece nu poate fi separat.
O frază obișnuită pe care o veți auzi este "să depună eforturi pentru o cuplare scăzută și o coeziune ridicată". Această frază este o reamintire utilă că ar trebui să ne străduim pentru un cod care separă sarcinile și nu se bazează foarte mult unul asupra celuilalt. Astfel, cuplarea joasă (sau liberă) este în general bună, în timp ce cuplarea ridicată (sau strânsă) este, în general, rea.
Mai întâi, permiteți să priviți obiectele asteroizilor și modul în care sunt conectate. Amintiți-vă că obiectele sunt o navă, un asteroid, o farfurie zburătoare și un glonț. Cum sunt aceste obiecte legate sau conectate unul la altul?
În asteroizi, o navă poate trage un glonț, un glonț poate lovi un asteroid și o farfurie zburătoare, iar un asteroid și o farfurie zburătoare pot lovi nava. Diagrama relațiilor noastre arată după cum urmează:
După cum puteți vedea obiectele sunt destul de bine interconectate. Din acest motiv, trebuie să fim atenți la modul în care scriem codul, altfel vom ajunge la un sistem cuplat strâns. Să luăm de exemplu nava care trage un glonț. Dacă nava avea să creeze un obiect de glonț, să țină evidența poziției sale și apoi să modifice asteroidul atunci când loviturile de glonț, sistemul nostru ar fi foarte strâns cuplat.
În schimb, nava ar trebui să creeze un obiect bullet, dar nu vă faceți griji după acest punct. O altă clasă ar fi responsabilă pentru urmărirea poziției glonțului, precum și a ceea ce se întâmplă atunci când un glonț lovește un asteroid. Cu o clasă intermediară între relațiile noastre, diagrama ar arăta după cum urmează:
Această diagramă de relații pare mult mai bună și creează un sistem foarte cuplat. În acest sistem, dacă adăugăm un obiect, cum ar fi un meteor, putem face acest lucru fără a fi nevoie să schimbăm modul în care funcționează obiectele de pe navă sau bullet - tocmai l-am lăsat pe clasa noastră intermediară să aibă grijă de toate acestea.
Întrucât există un singur obiect în Tetris, Tetrimino, cuplarea nu este într-adevăr o problemă, deoarece nu pot exista relații cu alte obiecte.
Pentru Pac-Man, cuplarea strânsă poate apărea atunci când Pac-Man mănâncă o peletă electrică. Când se consumă un pelet de putere, Pac-Man poate mânca apoi fantome și schimbările de stat ale fantomelor comestibil
. Dacă obiectul Pac-Man ar fi urmărit când a mâncat un pelet de putere și apoi a inițiat starea de schimbare a fiecărei fantome, sistemul ar fi cuplat strâns.
Din nou, este necesară o altă clasă pentru a urmări aceste informații și a le procesa astfel încât obiectele noastre să poată fi cuplate în mod liber. Mai jos este un exemplu despre modul în care o clasă intermediare ar putea să urmărească Pac-Man consumând o peletă electrică.
/ ** * Clasa Intermediară care urmărește evenimentele de joc * / clasa publica de joc ... if (Pac-Man.eats (Power_Pellet)) Ghosts.changeState (); ...
Cuplarea este principiul reducerii modului în care obiectele afectează în mod direct stările și comportamentele altor obiecte. Cuplarea ajută la crearea unui cod care este mai ușor de citit și mai ușor de schimbat.
În următorul sfat rapid, vom discuta principiul încapsulare și de ce ajută la crearea unui cod de întreținere. Urmăriți-ne pe Twitter, Facebook sau Google+ pentru a fi la curent cu cele mai recente postări.