Destul de des întâlnesc dezvoltatori care nu au auzit de principiile SOLID (noi . — Transl.) sau programare orientată pe obiecte (OOP), sau ați auzit de ele, dar nu le folosiți în practică. Acest articol descrie beneficiile principiilor OOP care ajută dezvoltatorul în munca sa de zi cu zi. Unele dintre ele sunt bine cunoscute, altele nu atât de mult, așa că articolul va fi util atât pentru începători, cât și pentru programatori experimentați.
Amintim: pentru toți cititorii Habr - o reducere de 10 de ruble la înscrierea la orice curs Skillbox folosind codul promoțional Habr.
Skillbox recomandă: Curs educativ online .
USCAT (nu te repeta)
Un principiu destul de simplu, a cărui esență este clară din nume: „Nu te repeta”. Pentru un programator, aceasta înseamnă necesitatea de a evita codul duplicat, precum și posibilitatea de a folosi abstractizarea în munca sa.
Dacă în cod există două secțiuni care se repetă, acestea ar trebui combinate într-o singură metodă. Dacă o valoare codificată este folosită de mai multe ori, merită convertită într-o constantă publică.
Acest lucru este necesar pentru a simplifica codul și a-l face mai ușor de întreținut, care este scopul principal al OOP. Nici nu ar trebui să folosiți excesiv uniunea, deoarece același cod nu va trece verificarea atât cu OrderId, cât și cu SSN.
Încapsularea schimbărilor
Majoritatea produselor software ale companiilor sunt în continuă evoluție. Aceasta înseamnă că trebuie făcute modificări la cod, acesta trebuie să fie suportat. Vă puteți face viața mai ușoară utilizând încapsularea. Acest lucru vă va permite să testați și să mențineți mai eficient baza de cod existentă. .
Dacă scrieți în Java, atunci .
Principiul deschis/închis
Acest principiu poate fi reținut cu ușurință citind următoarea afirmație: „Entitățile software (clase, module, funcții etc.) ar trebui să fie deschise pentru extindere, dar închise pentru modificare.” În practică, aceasta înseamnă că pot permite modificarea comportamentului lor fără a schimba codul sursă.
Principiul este important atunci când modificările aduse codului sursă necesită revizuirea codului, testarea unitară și alte proceduri. Codul care urmează principiul deschis/închis nu se schimbă atunci când este extins, așa că există mult mai puține probleme cu acesta.
Iată un exemplu de cod care încalcă acest principiu.
Dacă trebuie să schimbați ceva în el, va dura mult timp, deoarece toate secțiunile codului care au o conexiune cu fragmentul dorit vor trebui modificate.
Apropo, deschiderea-închiderea este unul dintre principiile SOLID.
Principiul responsabilității unice (SRP)
Un alt principiu din setul SOLID. Se afirmă că „nu există decât o singură cauză care provoacă o schimbare în clasă”. Clasa rezolvă o singură problemă. Poate avea mai multe metode, dar fiecare dintre ele este folosită doar pentru a rezolva o problemă comună. Toate metodele și proprietățile ar trebui să servească numai la asta.
Valoarea acestui principiu este că slăbește cuplajul dintre componenta software individuală și cod. Dacă adăugați mai mult de o funcționalitate la o clasă, aceasta introduce o relație între cele două funcții. Astfel, dacă schimbi unul dintre ele, există șanse mari de a-l strica pe al doilea, care este legat de primul. Și asta înseamnă creșterea ciclurilor de testare pentru a identifica toate problemele în avans.
Principiul inversării dependenței (DIP)
Mai sus este un exemplu de cod în care AppManager depinde de EventLogWriter, care, la rândul său, este strâns cuplat cu AppManager. Dacă aveți nevoie de o modalitate diferită de a afișa o notificare, fie că este push, SMS sau e-mail, trebuie să schimbați clasa AppManager.
Problema poate fi rezolvată folosind DIP. Deci, în loc de AppManager, solicităm un EventLogWriter, care va fi introdus folosind cadrul.
DIP face posibilă înlocuirea cu ușurință a modulelor individuale cu altele prin schimbarea modulului de dependență. Acest lucru face posibilă schimbarea unui modul fără a-i afecta pe celelalte.
Compoziția în loc de moștenire
Există două modalități principale de reutilizare a codului: moștenirea și compoziția, ambele având propriile avantaje și dezavantaje. De obicei, al doilea este preferat pentru că este mai flexibil.
Compoziția vă oferă posibilitatea de a modifica comportamentul unei clase în timpul execuției prin setarea proprietăților acesteia. La implementarea interfețelor se folosește polimorfismul, ceea ce oferă o implementare mai flexibilă.
Chiar și Effective Java de Joshua Bloch sfătuiește să alegeți compoziția în locul moștenirii.
Principiul înlocuirii Barbara Liskov (LSP)
Un alt principiu din trusa de instrumente SOLID. Afirmă că subtipurile trebuie să fie substituibile cu supertipul. Adică, metodele și funcțiile care funcționează cu o superclasă ar trebui să poată funcționa fără probleme cu subclasele sale.
LSP este asociat atât cu principiul responsabilității unice, cât și cu principiul responsabilității partajate. Dacă o clasă oferă mai multe funcționalități decât o subclasă, atunci aceasta din urmă nu va suporta o parte din funcționalitate, încălcând acest principiu.
Iată o bucată de cod care contrazice LSP.
Metoda ariei (Dreptunghi r) calculează aria unui dreptunghi. Programul se va bloca după executarea Square deoarece Square nu este un dreptunghi aici. Conform principiului LSP, funcțiile care folosesc referințe la clase de bază ar trebui să poată folosi obiecte ale claselor derivate fără instrucțiuni suplimentare.
Acest principiu, care este o definiție specifică a unui subtip, a fost propus de Barbara Liskov într-o conferință din 1987, intitulată „Abstracția datelor și ierarhia”, de unde și numele.
Principiul de separare a interfeței (ISP)
Un alt principiu SOLID. Potrivit acestuia, o interfață care nu este utilizată nu ar trebui implementată. Respectarea acestui principiu ajută sistemul să rămână flexibil și potrivit pentru refactorizare atunci când se fac modificări în logica de funcționare.
Cel mai adesea, această situație apare atunci când interfața conține mai multe funcții simultan, iar clientul are nevoie doar de una dintre ele.
Deoarece scrierea unei interfețe este o sarcină dificilă, schimbarea acesteia după finalizarea lucrării fără a rupe nimic va fi o provocare.
Avantajul principiului ISP în Java este că toate metodele trebuie implementate mai întâi și abia apoi pot fi folosite de clase. Prin urmare, principiul face posibilă reducerea numărului de metode.
Programare pentru interfață, nu implementare
Totul aici este clar din nume. Aplicarea acestui principiu duce la crearea unui cod flexibil care poate funcționa cu orice nouă implementare a interfeței.
Следует использовать тип интерфейса для переменных, возвращаемых типов или же типа аргумента метода. Пример — использование SuperClass, а не SubClass.
Adică:
Listă numere= getNumbers();
Dar nu:
numere ArrayList = getNumbers();
Iată o implementare practică a celor discutate mai sus.
Principiul delegării
Распространенный пример — методы equals() и hashCode() в Java. Когда требуется сравнить два объекта, то это действие делегируется соответствующему классу вместо клиентского.
Avantajul principiului este că nu există duplicare a codului și este relativ simplu să schimbi comportamentul. Se aplică și delegarii evenimentelor.
Toate aceste principii vă permit să scrieți un cod mai flexibil, mai frumos și mai fiabil, cu coeziune ridicată și cuplare scăzută. Desigur, teoria este bună, dar pentru ca un dezvoltator să folosească efectiv cunoștințele dobândite, este nevoie de practică. Odată ce ați stăpânit principiile POO, următorul pas ar putea fi să învățați modele de design pentru a rezolva problemele comune de dezvoltare a software-ului.
Skillbox recomandă:
- Curs practic .
- Curs aplicat online .
- Curs practic de doi ani .
Sursa: www.habr.com