În Java, Principii SOLIDE sunt o abordare orientată pe obiecte care sunt aplicate proiectării structurii software. Este conceptualizat de Robert C. Martin (cunoscut și sub numele de unchiul Bob). Aceste cinci principii au schimbat lumea programării orientate pe obiecte și, de asemenea, au schimbat modul de scriere a software-ului. De asemenea, se asigură că software-ul este modular, ușor de înțeles, depanat și refactor. În această secțiune, vom discuta Principii SOLID în Java cu exemplul potrivit .
testarea de compatibilitate
Acronim cuvântul SOLID pentru:
- Principiul responsabilității unice (SRP)
- Principiul deschis-închis (OCP)
- Principiul substituției Liskov (LSP)
- Principiul de segregare a interfeței (ISP)
- Principiul inversării dependenței (DIP)
Să explicăm principiile unul câte unul în detaliu.
Principiul responsabilității unice
Principiul răspunderii unice prevede că fiecare clasă Java trebuie să realizeze o singură funcționalitate . Implementarea mai multor funcționalități într-o singură clasă mashup codul și, dacă este necesară orice modificare, poate afecta întreaga clasă. Codul precis și codul poate fi întreținut cu ușurință. Să înțelegem principiul responsabilității unice printr-un exemplu.
Presupune, Student este o clasă având trei metode și anume printDetails(), calculatePercentage(), și addStudent(). Prin urmare, clasa Student are trei responsabilități de a tipări detaliile studenților, de a calcula procente și de baza de date. Folosind principiul responsabilității unice, putem separa aceste funcționalități în trei clase separate pentru a îndeplini scopul principiului.
Student.java
public class Student { public void printDetails(); { //functionality of the method } pubic void calculatePercentage(); { //functionality of the method } public void addStudent(); { //functionality of the method } } Fragmentul de cod de mai sus încalcă principiul responsabilității unice. Pentru a atinge scopul principiului, ar trebui să implementăm o clasă separată care îndeplinește doar o singură funcționalitate.
Student.java
public class Student { public void addStudent(); { //functionality of the method } } PrintStudentDetails.java
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } Procent.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } Prin urmare, am atins obiectivul principiului responsabilității unice prin separarea funcționalității în trei clase separate.
Principiul deschis-închis
Aplicatia sau modulul entizeaza metodele, functiile, variabilele etc. Principiul deschis-inchis prevede ca in functie de noi cerinte modulul ar trebui să fie deschis pentru extindere, dar închis pentru modificare. Extensia ne permite să implementăm noi funcționalități în modul. Să înțelegem principiul printr-un exemplu.
Presupune, Informații despre vehicul este o clasă și are metoda vehiculNumăr() care returnează numărul vehiculului.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } Dacă vrem să adăugăm o altă subclasă numită Truck, pur și simplu, adăugăm încă o declarație if care încalcă principiul deschis-închis. Singura modalitate de a adăuga subclasa și de a atinge obiectivul de principiu prin suprascrierea vehiculNumăr() metoda, așa cum am arătat mai jos.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber() { //functionality } } public class Car extends VehicleInfo { public double vehicleNumber() { return this.getValue(); } public class Car extends Truck { public double vehicleNumber() { return this.getValue(); } În mod similar, putem adăuga mai multe vehicule făcând o altă subclasă care se extinde din clasa de vehicule. abordarea nu ar afecta aplicația existentă.
Principiul substituirii Liskov
Principiul substituției Liskov (LSP) a fost introdus de Barbara Liskov . Se aplică moștenirii în așa fel încât clasele derivate trebuie să fie complet substituibile cu clasele lor de bază . Cu alte cuvinte, dacă clasa A este un subtip al clasei B, atunci ar trebui să putem înlocui B cu A fără a întrerupe comportamentul programului.
câte orașe sunt în noi
Acesta extinde principiul deschidere-închidere și se concentrează, de asemenea, pe comportamentul unei superclase și subtipurile acesteia. Ar trebui să proiectăm clasele pentru a păstra proprietatea, dacă nu avem un motiv serios să facem altfel. Să înțelegem principiul printr-un exemplu.
Student.java
public class Student { private double height; private double weight; public void setHeight(double h) { height = h; } public void setWeight(double w) { weight= w; } ... } public class StudentBMI extends Student { public void setHeight(double h) { super.setHeight(h); super.setWeight(w); } public void setWeight(double h) { super.setHeight(h); super.setWeight(w); } } Clasele de mai sus au încălcat principiul substituției Liskov, deoarece clasa StudentBMI are constrângeri suplimentare, adică înălțimea și greutatea care trebuie să fie aceleași. Prin urmare, clasa Student (clasa de bază) nu poate fi înlocuită cu clasa StudentBMI (clasa derivată).
Prin urmare, înlocuirea clasei Student cu clasa StudentBMI poate duce la un comportament neașteptat.
Principiul segregării interfeței
Principiul prevede că interfețele mai mari se împart în altele mai mici. Deoarece clasele de implementare folosesc numai metodele necesare. Nu trebuie să forțăm clientul să folosească metodele pe care nu dorește să le folosească.
Scopul principiului segregării interfeței este similar cu principiul responsabilității unice. Să înțelegem principiul printr-un exemplu.
Să presupunem că am creat o interfață numită Conversie având trei metode intToDouble(), intToChar(), și charToString() .
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } Interfața de mai sus are trei metode. Dacă vrem să folosim doar o metodă intToChar(), nu avem de ales să implementăm metoda unică. Pentru a depăși problema, principiul ne permite să împărțim interfața în trei separate.
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } Acum putem folosi doar metoda care este necesară. Să presupunem că dorim să convertim întregul în dublu și caracterul în șir, atunci vom folosi numai metodele intToDouble() și charToString().
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } Principiul inversării dependenței
Principiul prevede că trebuie să folosim abstractizarea (clase și interfețe abstracte) în loc de implementări concrete. Modulele de nivel înalt nu ar trebui să depindă de modulul de nivel scăzut, dar ambele ar trebui să depindă de abstractizare. Pentru că abstracția nu depinde de detaliu, ci detaliul depinde de abstracție. Decuplează software-ul. Să înțelegem principiul printr-un exemplu.
public class WindowsMachine { //functionality } Merită, dacă nu avem tastatură și mouse, să lucrăm pe Windows. Pentru a rezolva această problemă, creăm un constructor al clasei și adăugăm instanțele tastaturii și monitorului. După adăugarea instanțelor, clasa arată astfel:
public class WindowsMachine { public final keyboard; public final monitor; public WindowsMachine() { monitor = new monitor(); //instance of monitor class keyboard = new keyboard(); //instance of keyboard class } } Acum putem lucra pe mașina Windows cu ajutorul unei tastaturi și al mouse-ului. Dar încă ne confruntăm cu problema. Pentru că am cuplat strâns cele trei clase, folosind noul cuvânt cheie. Este greu să testați mașina de clasă Windows.
Pentru a face codul cuplat liber, decuplăm WindowsMachine de tastatură utilizând interfața Keyboard și acest cuvânt cheie.
1 milion câte 0
Tastatură.java
public interface Keyboard { //functionality } WindowsMachine.java
public class WindowsMachine { private final Keyboard keyboard; private final Monitor monitor; public WindowsMachine(Keyboard keyboard, Monitor monitor) { this.keyboard = keyboard; this.monitor = monitor; } } În codul de mai sus, am folosit injecția de dependență pentru a adăuga dependența de tastatură în clasa WindowsMachine. Prin urmare, am decuplat clasele.
De ce ar trebui să folosim principiile SOLID?
- Reduce dependențele, astfel încât un bloc de cod poate fi schimbat fără a afecta celelalte blocuri de cod.
- Principiile menite să facă designul mai ușor, ușor de înțeles.
- Prin utilizarea principiilor, sistemul este menținut, testabil, scalabil și reutilizabil.
- Evită designul prost al software-ului.
Data viitoare când proiectați software, țineți cont de aceste cinci principii. Prin aplicarea acestor principii, codul va fi mult mai clar, mai testabil și mai ușor de utilizat.