1.2. Principiile S.O.L.I.D.
În general este foarte ușor să scriem cod fără a ne gândi la modul în care îl vom întreţine. Scopul meu însă a fost din start să încep o aplicaţie pe care să o rafinez pe parcurs. Modul în care intenţionez să dezvolt această aplicație este aderând la principiile care organizat dau acronimul S.O.L.I.D. Le voi prezenta nu în ordinea din acronim, ci în stilul pe care l-am descoperit cel mai ușor de asimilat. Aceste principii sunt acceptate ca și standarde în comunitate software actuală, problema rămâne totuși cum le aplicăm și cum le interpretăm.
1.2.1. Single Responsability Principle - principiul responsabilităţii unice
Acest principiu afirmă că o clasă trebuie să aibe un singur motiv pentru a fi modificată.
Este relativ greu de întreţinut arhitectura unei aplicaţii. Cu cât aduci mai mulţi oameni pe proiect și cu cât investești mai mult în anumite facilităţi, degradarea sistemului în general se face simţită. Acest principiu propune o strategie care forţează scrierea de obiecte simple, care au o responsabilitate exactă, ușor de urmărit și modificat. Fiind vorba de o singură responsabilitate, probabilitatea ca schimbarea să afecteze alt cod este destul de restrânsă. Comportamentul se va schimba evident, dar codul nu. Și în cazul unei erori, responsabilul e relativ ușor de identificat. [MartinSRP, Nijhof]
1.2.2. Dependency Injection
Acest principiu afirmă că "Modulele de nivel înalt nu ar trebui să depindă de modulele din nivelele inferioare, ambele ar trebui să depinde de abstracţii" și "Abstracţiile nu ar trebui să depindă de detalii, detaliile ar trebui să depindă de abstracţii". Sună bizar de primele 12 ori când îl citești, dar parcă ceva sună bine, indicația ar fi să nu se folosească nicăieri în cod referinţe la clase concrete ci doar la interfeţe și/sau clase abstracte, concretizările acestor vor fi injectate fie de către un alt obiect/altă clasă.
Există 3 forme de injectare:
-
Injectare prin constructor: dependințele sunt declarate în constructor, satisfacerea acestor dependințe fiind lăsată pe seama celui care crează instanța
-
Injectare prin elemente setter10: dependințele sunt injectate prin intermediul unei funcții care respectă convenția de nume setXXX, unde XXX este numele proprietății.
-
Injectare prin interfață: se declară interfețe care vor avea funcții injectXXX pentru fiecare dependință pe care vrem să o injectăm. [MartinDIP, Nijhof, FowlerDI]
1.2.3 Open Closed Principle
"Clasele ar trebui să fie deschise extensiei și închise modificărilor". Semnificaţia este următoare, dacă e nevoie să se modifice ceva din comportamentul extern al clasei sau dependinţele acesteia, acea modificare trebuie să fie posibilă fără a schimba codul clasei. Cheia pentru a obține acest comportament este utilizarea abstractizării. Din moment ce clasa încapsulează logica utilizând abstracții, înseamnă că putem schimba implementările acelor abstracții și se va modifica și comportamentul, dar nu codul.[MartinOCP, Nijhof]
1.2.4 Liskov Substitution Principle
"Funcţiile care utilizează pointeri sau referinţe la clasele de bază trebuie să poată folosi obiecte sau clase derivate fără să știe acest lucru". În principiu înseamnă că o dată comportamentul clasei stabilit modifcările pe care le fac asupra claselor din afara domeniul desemnat de obiect nu ar trebui să ma forţeze să modific comportamentul intern al clasei mele.[MartinLSP,Nijhof]
"Clienţii nu ar trebui să fie forţaţi să depindă de interfeţe pe care nu le folosesc". Semnificaţia este că dacă un client depinde de anumite utilizări, a nu se confunda cu diferite responsabilităţi, atunci ar trebui să fie o interfaţă specifică pentru fiecare dintre utilizări.[MartinISP, Nijhof]
1.3. Inversiune a controlului
Încercarea de a face injectarea dependinţelor fără ceva formă de inversare a controlului ar fi foarte greu, în cel mai rău caz ar provoca coeziunea la un nivel mult mai înalt. Cu ce se ocupă acest container de inversare a controlului? În forma lui cea mai simplă este un Factory, conţine așadar logica necesară creării instanţelor unui obiect. În general am întâlnit cele două noţiuni, injectare de dependinţe și inversare a controlului împreună pentru că sunt strâns legate. Nu o să intru mai mult în detalii despre acest subiect. Este suficient de menţionat că această "unealtă" e capabilă să construiască obiecte și să le injecteze în general în constructorul obiectelor, sau prin intermediul proprietăţilor. Personal prefer să declar dependinţele de anumite obiecte în constructor, în felul acesta ofer o imagine foarte clară a dependinţelor obiectului, și mă asigur că o anumită referinţă mi-e disponibilă din momentul în care o nouă instanţă mi-a fost creată. Sincer să fiu nu cred că am avut încă ocazia să descopăr un loc în care aș prefera sa folosesc o proprietate a obiectului ca și punct de injectare și nu în constructor.[Nijhof]
1.4. Model View Controller
Acesta este un șablon de proiectare care specifică o metodă de separare a celor trei componenete care îi alcătuiesc numele. Motivul pentru care l-am listat este larga sa acceptare în framework-urile web actuale precum Spring MVC, Rails, Grails, Lift, Microsoft Asp.NET MVC. Modul în care sunt interpretatea sau acceptate aceste componente ale șablonului diferă în general în funcție de modul în care autorii l-au adaptat.
Foarte pe scurt din [GoF], modelul reprezintă obiectul aplicației, view-ul reprezintă partea de prezentare și controller-ul definește modul în care aplicația reacționează la input-ul utilizatorului.
Ce a dus la acceptarea aproape universală a acestui șablon în mediul web? Motivația a venit din faptul că partea de prezentare este modifică mult mai des decât logica aplicației, ceea automat duce la necesitatea separării celor două. Logica aplicației este formată din răspunsul pe care îl returnăm utilizatorului în urma unei acțiuni (controller) și gestiunea mecanismelor din culise (model). Prezentarea este stratul responsabil cu afișarea datelor care vin dinspre controller. Dintre beneficiile acestui șablon amintim: suportul pentru multe ecrane, se acomodează relativ ușor schimbărilor; dezavantajele sunt: complexitatea – întrucât introduce un nou nivel de indirectare, modificarea frecventă a datelor ar putea crea prea multe update-uri parții de prezentare.[HaackMV, msdnMVCPattern, Connery2009]
Dostları ilə paylaş: |
