În dezvoltarea de software, Design orientat pe obiecte joacă un rol crucial atunci când vine vorba de scrierea de cod flexibil, scalabil, întreținut și reutilizabil. Există atât de multe beneficii ale utilizării OOD, dar fiecare dezvoltator ar trebui să cunoască și principiul SOLID pentru un design bun orientat pe obiecte în programare. Principiul SOLID a fost introdus de Robert C. Martin, cunoscut și sub numele de Unchiul Bob și este un standard de codare în programare. Acest principiu este un acronim al celor cinci principii care sunt prezentate mai jos:
- Principiul responsabilității unice (SRP)
- Principiul deschis/închis
- Principiul substituirii lui Liskov (LSP)
- Principiul de segregare a interfeței (ISP)
- Principiul inversării dependenței (DIP)
Principiul SOLID ajută la reducerea cuplării strânse. Cuplarea strânsă înseamnă că un grup de clase este foarte dependent unul de celălalt, ceea ce ar trebui să îl evitați în codul dvs.
- Opusul cuplării strânse este cuplarea liberă, iar codul dvs. este considerat un cod bun atunci când are clase slab cuplate.
- Clasele cuplate vag minimizează modificările din codul dvs., ajută la a face codul mai reutilizabil, mai ușor de întreținut, mai flexibil și mai stabil. Acum să discutăm unul câte unul aceste principii...
1. Principiul responsabilității unice
Acest principiu prevede că O clasă ar trebui să aibă un singur motiv să se schimbe ceea ce înseamnă că fiecare clasă ar trebui să aibă o singură responsabilitate sau un singur loc de muncă sau un singur scop. Cu alte cuvinte, o clasă ar trebui să aibă un singur loc de muncă sau scop în cadrul sistemului software.
exemplu de cod java
Să înțelegem principiul responsabilității unice folosind un exemplu:
Imaginați-vă un brutar care este responsabil cu coacerea pâinii. Rolul brutarului este să se concentreze asupra sarcinii de coacere a pâinii, asigurându-se că pâinea este de înaltă calitate, coaptă corespunzător și îndeplinește standardele brutăriei.
char + int în java
- Cu toate acestea, dacă brutarul este responsabil și pentru gestionarea inventarului, comandarea consumabilelor, servirea clienților și curățarea brutăriei, acest lucru ar încălca SRP.
- Fiecare dintre aceste sarcini reprezintă o responsabilitate separată, iar prin combinarea lor, concentrarea și eficiența brutarului în coacerea pâinii ar putea fi compromise.
- Pentru a adera la SRP, brutăria ar putea atribui diferite roluri diferitelor persoane sau echipe. De exemplu, ar putea exista o persoană sau o echipă separată responsabilă cu gestionarea inventarului, o alta pentru comandarea consumabilelor, o alta pentru deservirea clienților și alta pentru curățarea brutăriei.
2. Principiul deschis/închis
Acest principiu prevede că Entitățile software (clase, module, funcții etc.) ar trebui să fie deschise pentru extindere, dar închise pentru modificare ceea ce înseamnă că ar trebui să puteți extinde un comportament de clasă, fără a-l modifica.
Să înțelegem principiul deschis/închis folosind un exemplu:
Imaginează-ți că ai o clasă numită
PaymentProcessor>care procesează plățile pentru un magazin online. Inițial, celPaymentProcessor>clasa acceptă doar procesarea plăților folosind carduri de credit. Cu toate acestea, doriți să extindeți funcționalitatea acesteia pentru a accepta și procesarea plăților folosind PayPal.
În loc să modifice cele existentePaymentProcessor>clasă pentru a adăuga suport PayPal, puteți crea o nouă clasă numităPayPalPaymentProcessor>care extindePaymentProcessor>clasă. În acest fel,PaymentProcessor>clasa rămâne închisă pentru modificare, dar deschisă pentru extindere, aderând la Principiul Deschis-Închis
3. Principiul substituirii lui Liskov
Principiul a fost introdus de Barbara Liskov în 1987 și conform acestui principiu Clasele derivate sau secundare trebuie să fie înlocuibile cu clasele lor de bază sau părinte . Acest principiu asigură că orice clasă care este fiul unei clase părinte ar trebui să fie utilizabilă în locul părintelui, fără niciun comportament neașteptat.
Să înțelegem principiul substituției lui Liskov folosind un exemplu:
Unul dintre exemplele clasice ale acestui principiu este un dreptunghi cu patru laturi. Înălțimea unui dreptunghi poate fi orice valoare, iar lățimea poate fi orice valoare. Un pătrat este un dreptunghi cu lățime și înălțime egale. Deci putem spune că putem extinde proprietățile clasei dreptunghi în clasă pătrată.
setați java
Pentru a face acest lucru, trebuie să schimbați clasa copil (pătrat) cu clasa părinte (dreptunghi) pentru a se potrivi definiției unui pătrat având patru laturi egale, dar o clasă derivată nu afectează comportamentul clasei părinte, așa că dacă veți face că va încălca Principiul substituirii Liskov.
4. Principiul segregării interfeței
Acest principiu este primul principiu care se aplică interfețelor în loc de clase în SOLID și este similar cu principiul responsabilității unice. Se afirmă că nu forțați niciun client să implementeze o interfață care este irelevantă pentru el . Aici obiectivul dvs. principal este să vă concentrați pe evitarea interfeței grase și să acordați preferință multor interfețe mici specifice clientului. Ar trebui să preferați mai multe interfețe client decât o interfață generală și fiecare interfață ar trebui să aibă o responsabilitate specifică.
Să înțelegem principiul segregării interfeței folosind un exemplu:
Să presupunem că intri într-un restaurant și ești vegetarian pur. Chelnerul din acel restaurant ți-a dat cardul de meniu care include produse vegetariene, produse non-vegetariene, băuturi și dulciuri.
- În acest caz, în calitate de client, ar trebui să aveți o carte de meniu care să includă doar produse vegetariene, nu tot ceea ce nu mâncați în mâncare. Aici meniul ar trebui să fie diferit pentru diferite tipuri de clienți.
- Cartela de meniu comună sau generală pentru toată lumea poate fi împărțită în mai multe cărți în loc de doar una. Utilizarea acestui principiu ajută la reducerea efectelor secundare și a frecvenței modificărilor necesare.
5. Principiul inversării dependenței
Principiul inversării dependenței (DIP) este un principiu în proiectarea orientată pe obiecte care afirmă că Modulele de nivel înalt nu ar trebui să depindă de modulele de nivel scăzut. Ambele ar trebui să depindă de abstracții . În plus, abstracțiile nu ar trebui să depindă de detalii. Detaliile ar trebui să depindă de abstracții.
tipuri de date java
- În termeni mai simpli, DIP sugerează că clasele ar trebui să se bazeze pe abstracții (de exemplu, interfețe sau clase abstracte) mai degrabă decât pe implementări concrete.
- Acest lucru permite un cod mai flexibil și decuplat, facilitând modificarea implementărilor fără a afecta alte părți ale bazei de cod.
Să înțelegem principiul inversării dependenței folosind un exemplu:
Într-o echipă de dezvoltare software, dezvoltatorii depind de un sistem abstract de control al versiunilor (de exemplu, Git) pentru a gestiona și urmări modificările aduse bazei de cod. Ele nu depind de detalii specifice despre cum funcționează Git intern.
Acest lucru permite dezvoltatorilor să se concentreze pe scrierea codului fără a fi nevoie să înțeleagă complexitățile implementării controlului versiunilor.