SOLID, care este toți dezvoltatorii de software ar trebui să privească principii, este abrevierea acestor principii. Aceste principii au obiective precum cod curat și flexibil. Acesta își propune să prevină duplicarea codului și să creeze cod durabil. A fost găsit de Robert C. Martin, Acronimul a fost conceput de Michael Feathers.

Principiile SOLID, pe de altă parte, sunt regulile care trebuie urmate atunci când se dezvoltă software cu un limbaj de programare orientată pe obiecte. Aceste principii au cinci subtitrări.

• Single Responsibility Principle,
• Open/Closed Principle,
• Liskov Subtitution Principle,
• Interface Segregation Principle,
• Dependency Inversion Principle

 

S – Single Responsibility Principle

Nu ar trebui să atribuie mai mult de o sarcină unei clase sau funcție și să o facă responsabilă pentru multe sarcini. Clasa sau funcția ar trebui să aibă o singură activitate de făcut.

 

– Open/Closed Principle

În acest principiu, scopul este de a forma baza scrierii codului într-o structură durabilă și reutilizabilă. Obiectele dezvoltate în proiect trebuie să fie deschise dezvoltării, dar închise schimbării. Adică, un obiect ar trebui să poată dobândi proprietăți noi fără a-și schimba comportamentul.

 

L – Liskov Substitution Principle

Acest principiu urmărește ca clasele moștenite trebuie să aibă mai întâi toate caracteristicile din clasa care a fost moștenită și apoi trebuie să aibă propriile caracteristici.

 

I – Interface Segregation Principle

 

 

În loc să creați prea multe responsabilități pentru o singură interfață, ar trebui să fie create mai multe interfețe personalizate. Obiectele nu trebuie forțate să nu moștenească interfețe care conțin proprietăți sau metode de care nu au nevoie. Single Responsibility Principle este aproape același cuInterface Segregation Principle. Totuși, punctul de remarcat aici este că, în timp ce acest principiu se ocupă de interfață, responsabilitatea unică se ocupă de clase sau metode.

 

– Dependency Inversion Principle

 

 

Scopul acestui principiu este de a minimiza dependențele. Adică, modificările aduse subclaselor nu ar trebui să afecteze superclasele. Pentru a rezolva această problemă, trebuie să gestionăm ambele clase peste concepte abstracte prin crearea unui strat de abstractizare între clasa de nivel superior și clasa de nivel inferior.

Putem spune că conceptul de inversare a dependenței este o metodă de soluție pentru injectarea dependenței. Puteți revizui subiectul „Dependency Injection” făcând clic aici.