Trei principii de proiectare orientate pe obiecte pe care ar trebui să le folosiți cu siguranță! învățați să programați
Tastaturi:
- Care este principiul Hollywood-ului?
- Ce înseamnă inversiunea dependenței?
- Ce se înțelege prin principiul celei mai mici cunoștințe?
- Ce este legea Demeters?
Am vorbit deja de ce respectarea anumitor reguli ne poate salva de un set de ochi albaștri.
Pe de o parte, nu lucrăm singuri, mai ales la proiecte mai mari, iar colegii noștri trebuie să poată lucra cu codul nostru fără o criză nervoasă și să-l poată refolosi.
Dar, bineînțeles, beneficiem și de noi.
Plăcinta cu mere a bunicii este cea mai bună!
Deci, de ce să schimbăm rețeta atunci când putem rezolva o problemă într-un mod dovedit și, mai presus de toate, cunoscut.
Prin urmare, în acest articol dorim să ne ocupăm de încă trei principii de proiectare orientate pe obiecte.
Principiul hollywoodian
Nu ne sunați, vă sunăm!
Sau în germană: Vă vom contacta!
Acesta este modul în care agenții de la Hollywood văd că dau afară candidații.
De îndată ce un candidat se dovedește a fi potrivit, acesta este informat de acest lucru de către agent. În schimb, însă, agentul nu poate fi contactat de candidat.
Evenimentele sunt un concept orientat obiect, care funcționează exact conform acestui principiu.
De exemplu, cum funcționează evenimentele în cadrul unui procesor de text?
Un procesor de text, cum ar fi Word, constă din două zone.
Pe de o parte, zona în care editați documentul text și, pe de altă parte, un meniu în care puteți specifica fontul, dimensiunea fontului sau culoarea textului, de exemplu.
Cine este agentul aici și cine este candidatul?
În loc de candidat și agent, vorbim despre abonat și observator în programare.
Cu siguranță nu ar fi deosebit de eficient dacă zona documentului întreabă în mod constant meniul de formatare dacă utilizatorul a ajustat formatarea textului.
Prin urmare, de îndată ce utilizatorul a formatat textul prin meniu, se declanșează un eveniment despre care este informată zona documentului și apoi reacționează în consecință.
Prin urmare, în acest exemplu, meniul de formatare preia rolul de observator (agent), iar zona documentului este abonatul care așteaptă notificările din meniu.
Principiul Hollywoodului are o importanță deosebită în legătură cu așa-numitele cadre.
Cadrele sunt biblioteci de programe care scutesc dezvoltatorul de anumite sarcini standard.
De exemplu, există cadre precum Java FX, care preia interacțiunea cu utilizatorul pe o interfață grafică pentru noi.
De exemplu, dacă utilizatorul face clic pe un buton, suntem informați despre această acțiune prin intermediul cadrului și putem reacționa în consecință.
Principiul inversării dependenței
Următorul principiu pe care dorim să îl luăm în considerare este principiul inversării dependenței.
Acest principiu pune abstractizarea și implementarea independentă în prim plan.
Nu ne preocupă electricitatea, ci doar prizele.
Pentru a putea implementa acest principiu, folosim așa-numitul model proxy, care permite utilizarea unei metode indiferent de implementarea sa specifică.
Instrumentul pe care îl folosim pentru aceasta sunt interfețele Java.
Operațiuni de bază de date CRUD
Un exemplu celebru al principiului inversării dependenței este conexiunea la o bază de date prin intermediul JPA (Java Persistence Architecture).
JPA servește ca o interfață cu sistemul de baze de date utilizat.
În fiecare bază de date avem nevoie de așa-numitele operații CRUD Creare, citire, actualizare și ștergere cu care putem crea, citi, modifica și șterge intrările bazei de date.
Cu toate acestea, implementarea acestor operațiuni diferă între diferitele sisteme de baze de date.
De exemplu, implementarea acestor operațiuni pe o bază de date Oracle este diferită de cea dintr-o bază de date MySql.
Fără JPA ar trebui să scriem o implementare CRUD separată pentru fiecare sistem de baze de date.
De exemplu, am avea apoi o metodă de salvare separată, cum ar fi saveSQL, savePostgresSQL sau saveOracle pentru fiecare sistem de baze de date .
Și dezvoltatorul care dorește să utilizeze operația de salvare ar trebui să verifice de fiecare dată ce sistem de baze de date este utilizat și, în funcție de aceasta, să apeleze metoda CRUD corectă.
Dacă cineva ar trebui să aibă ideea să schimbe sistemul de baze de date, sunt necesare ajustări corespunzătoare ale codului.
Datorită interfeței JPA, ne scutește de asta. În funcție de sistemul de baze de date utilizat, putem andoca dinamic implementarea adecvată la proxy JPA (chiar și în timp ce programul rulează).
Dezvoltatorul care dorește să utilizeze operația CRUD poate apela apoi interfața metodelor CRUD, cum ar fi salvarea, indiferent de implementarea de bază.
Diferitele implementări în sine sunt independente una de cealaltă.
Principiul celei mai mici cunoștințe!
Am vorbit despre asta de multe ori. Programatorii sunt leneși și caută mereu modalități de a-și salva munca.
O modalitate bună de a face acest lucru este să folosiți munca realizată de alți dezvoltatori.
Cu toate acestea, acest lucru este util numai dacă timpul de familiarizare cu codul de program străin este cât mai scurt posibil.
Și aici intervine așa-numitul principiu al celei mai mici cunoștințe, sau în germană principiul științei puțin.
Acest principiu are o importanță deosebită în legătură cu proiectarea API (Application Programming Interface).
Știi cu siguranță și asta? Dacă aveți o întrebare. La cine te adresezi Un bun prieten sau un străin din zona pietonală?
Probabil că preferați să vă contactați prietenul. Sau?
Și tocmai aceasta este baza pe care se bazează principiul celei mai mici cunoștințe, care este cunoscut și sub denumirea de Legea lui Demeter.
Legea lui Demeter recomandă să întrebăm mai întâi un prieten și abia apoi să contactăm un străin dacă prietenul nostru nu ne poate ajuta.
Cine este prieten și cine este străin?
Cu siguranță nu ați avut niciodată o bere cu o metodă, clasă sau atribut. Sau? Deci, cum definim în programele noastre cine este un prieten și cine este un străin?.
Întrucât Legea lui Demiter este un principiu de proiectare orientat pe obiecte, trebuie să determinăm ce metode și atribute ale unui obiect aparțin prietenilor noștri.
Este logic că toate metodele din cadrul aceleiași clase sunt prietene între ele. Prin urmare, apelul reciproc al metodelor din aceeași clasă este permis în Legea lui Demiter.
Cine altcineva este unul dintre prietenii noștri?
La fel, ne referim la toate obiectele pe care le trecem ca parametri atunci când apelăm o metodă ca prietenii noștri.
În plus, toate obiectele (și atributele lor) pe care le creăm în cadrul aceleiași clase aparțin, de asemenea, cercului nostru de prieteni.
Un indicator al faptului că încălcați legea lui Demiter este dacă metodele dvs. de apeluri au mai mult de un operator (.).
Bine, să exersăm ceea ce am învățat folosind un exemplu.
Suntem într-o bibliotecă.
O bibliotecă este alcătuită din rafturi.
Pentru a mapa acest obiect orientat în obiecte în Java, avem nevoie de două clase. O clasă pentru rafturi și o clasă pentru biblioteca în sine.
Rafturile aparțin evident bibliotecii. Prin urmare, rafturile sunt prietene cu biblioteca.
Fiecare raft conține numărul de cărți pe care le conține ca atribut.
Deci atributul numărului de cărți este un prieten al clasei Bookshelf, dar nu al clasei Library .
Pentru că să presupunem că vrem să aflăm numărul de cărți de pe al zecelea raft al bibliotecii. Cum ar putea arăta un apel de metodă corespunzător?
Există două puncte în apelul nostru. Evident, încălcăm legea Demeters aici. Într-adevăr, atributul „număr de cărți” nu este un prieten al clasei bibliotecii.
Cum putem face apelul să se conformeze Legii Demeters?
Pentru a rezolva această problemă, trebuie să adăugăm o metodă la clasa bibliotecii care returnează direct numărul de cărți de pe un raft.
O astfel de metodă ar putea arăta astfel, de exemplu.
Deoarece rafturile sunt în bibliotecă, atributul raft este un prieten al clasei bibliotecii. Prin urmare, Legea Demeters nu este încălcată în cadrul metodei getAnzahlRegal.
Acum obținem numărul de cărți de pe raftul 10 cu următoarea metodă de apelare.
Deoarece metoda getAnzahlInRegal este un prieten al clasei de bibliotecă, nu am încălcat legea Demeters în acest caz.
Concluzie: În acest articol, ați aflat despre încă trei principii de proiectare orientate pe obiecte. Principiul hollywoodian este baza așa-numitelor cadre care ne scutesc de multe sarcini de rutină repetitive și adesea plictisitoare în practică.
Inversiunea dependenței ne permite să lucrăm cu API-urile (Interfețe de programare a aplicațiilor) separând definiția și implementarea unei funcții.
Principala preocupare a tuturor principiilor de proiectare, dar mai ales cu principiul celor mai puține cunoștințe, este mai ușor să vă faceți codul reutilizabil, mai ușor de înțeles și mai ușor de întreținut.
Ți-a plăcut articolul? Apoi urmează-ne imediat pe Facebook!
Kim Peter
Bună, mă numesc Kim și vreau să devin un mare programator. Participi?