V Javi, SOLID načela so objektno usmerjen pristop, ki se uporablja za načrtovanje strukture programske opreme. Konceptualizira ga Robert C. Martin (znan tudi kot stric Bob). Teh pet načel je spremenilo svet objektno usmerjenega programiranja in spremenilo tudi način pisanja programske opreme. Zagotavlja tudi, da je programska oprema modularna, enostavna za razumevanje, odpravljanje napak in preoblikovanje. V tem razdelku bomo razpravljali Načela SOLID v Javi s pravim zgledom .
Beseda SOLID je akronim za:
- Načelo enotne odgovornosti (SRP)
- Odprto-zaprto načelo (OCP)
- Liskovo substitucijsko načelo (LSP)
- Načelo ločevanja vmesnika (ISP)
- Načelo inverzije odvisnosti (DIP)
Razložimo načela enega za drugim podrobno.
Načelo ene same odgovornosti
To določa načelo enotne odgovornosti vsak razred Java mora opravljati eno samo funkcijo . Implementacija več funkcij v enem razredu združi kodo in če je potrebna kakršna koli sprememba, lahko vpliva na celoten razred. Je natančna koda in kodo je mogoče enostavno vzdrževati. Razumejmo načelo enotne odgovornosti na primeru.
Recimo, Študent je razred, ki ima tri metode in sicer printDetails(), izračunajodstotek(), in addStudent(). Zato ima razred študentov tri odgovornosti za tiskanje podrobnosti študentov, izračun odstotkov in bazo podatkov. Z uporabo načela enotne odgovornosti lahko te funkcije ločimo v tri ločene razrede, da izpolnimo cilj načela.
Študent.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 } } Zgornji delček kode krši načelo enotne odgovornosti. Da bi dosegli cilj načela, bi morali implementirati ločen razred, ki izvaja samo eno funkcijo.
Študent.java
public class Student { public void addStudent(); { //functionality of the method } } PrintStudentDetails.java
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } Odstotek.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } Tako smo dosegli cilj načela enotne odgovornosti z ločitvijo funkcionalnosti v tri ločene razrede.
Odprto-zaprto načelo
Aplikacija ali modul vsebuje metode, funkcije, spremenljivke itd. Odprto-zaprto načelo navaja, da v skladu z novimi zahtevami modul mora biti odprt za razširitev, vendar zaprt za spreminjanje. Razširitev nam omogoča implementacijo nove funkcionalnosti v modul. Razumejmo načelo s primerom.
Recimo, Informacije o vozilu je razred in ima metodo Številka vozila() ki vrne številko vozila.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } Če želimo dodati še en podrazred z imenom Truck, preprosto dodamo še en stavek if, ki krši načelo odprto-zaprto. Edini način za dodajanje podrazreda in doseganje načelnega cilja s preglasitvijo Številka vozila() metodo, kot smo pokazali spodaj.
Informacije o vozilu.java
javascript onload
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(); } Podobno lahko dodamo več vozil tako, da naredimo še en podrazred, ki se razširi iz razreda vozil. pristop ne bi vplival na obstoječo aplikacijo.
Načelo zamenjave Liskova
Liskovo substitucijsko načelo (LSP) je uvedel Barbara Liskov . Velja za dedovanje tako, da se izpeljani razredi morajo biti popolnoma nadomestljivi za svoje osnovne razrede . Z drugimi besedami, če je razred A podtip razreda B, bi morali biti sposobni zamenjati B z A, ne da bi prekinili delovanje programa.
Razširja načelo odpri-zapri in se osredotoča tudi na vedenje nadrazreda in njegovih podtipov. Razrede bi morali oblikovati tako, da bi ohranili lastnino, razen če imamo tehten razlog za drugače. Razumejmo načelo s primerom.
Študent.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); } } Zgornji razredi so kršili načelo zamenjave Liskova, ker ima razred ITM študenta dodatne omejitve, tj. višino in težo, ki morata biti enaki. Zato razreda Student (osnovni razred) ni mogoče nadomestiti z razredom Student BMI (izpeljani razred).
pretvori int v niz v javi
Zato lahko zamenjava razreda Student z razredom StudentBMI povzroči nepričakovano vedenje.
Načelo ločevanja vmesnika
Načelo pravi, da se večji vmesniki razdelijo na manjše. Ker izvedbeni razredi uporabljajo le metode, ki so zahtevane. Stranko ne smemo siliti v uporabo metod, ki jih ne želi uporabljati.
Cilj načela ločevanja vmesnikov je podoben načelu enotne odgovornosti. Razumejmo načelo s primerom.
Recimo, da smo ustvarili vmesnik z imenom Pretvorba s tremi metodami intToDouble(), intToChar(), in charToString() .
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } Zgornji vmesnik ima tri metode. Če želimo uporabiti samo metodo intToChar(), nimamo izbire za implementacijo ene same metode. Da bi odpravili težavo, nam načelo omogoča razdelitev vmesnika na tri ločene.
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } Zdaj lahko uporabimo samo tisto metodo, ki je potrebna. Recimo, da želimo pretvoriti celo število v dvojno in znak v niz, potem bomo uporabili samo metode intToDouble() in charToString().
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } Načelo inverzije odvisnosti
Načelo navaja, da moramo namesto konkretnih implementacij uporabiti abstrakcijo (abstraktne razrede in vmesnike). Moduli na visoki ravni ne smejo biti odvisni od modula na nizki ravni, ampak morata biti oba odvisna od abstrakcije. Ker abstrakcija ni odvisna od podrobnosti, ampak je podrobnost odvisna od abstrakcije. Loči programsko opremo. Razumejmo načelo s primerom.
public class WindowsMachine { //functionality } Vredno je, če nimamo tipkovnice in miške za delo v sistemu Windows. Za rešitev tega problema ustvarimo konstruktor razreda in dodamo primerke tipkovnice in monitorja. Po dodajanju primerkov je razred videti takole:
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 } } Zdaj lahko delamo na Windows stroju s pomočjo tipkovnice in miške. A še vedno se soočamo s problemom. Ker smo z uporabo nove ključne besede tesno povezali tri razrede. Težko je preizkusiti stroj razreda Windows.
Da bi bila koda ohlapno povezana, ločimo WindowsMachine od tipkovnice z uporabo vmesnika tipkovnice in te ključne besede.
Tipkovnica.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; } } V zgornji kodi smo uporabili vbrizgavanje odvisnosti za dodajanje odvisnosti tipkovnice v razred WindowsMachine. Zato smo razrede ločili.
Zakaj bi morali uporabljati načela SOLID?
- Zmanjša odvisnosti, tako da je blok kode mogoče spremeniti, ne da bi to vplivalo na druge bloke kode.
- Načela, namenjena lažjemu, razumljivemu oblikovanju.
- Z uporabo načel je sistem mogoče vzdrževati, ga je mogoče testirati, ga je mogoče razširiti in ga je mogoče ponovno uporabiti.
- Izogne se slabi zasnovi programske opreme.
Ko boste naslednjič načrtovali programsko opremo, imejte v mislih teh pet načel. Z uporabo teh načel bo koda veliko bolj jasna, preizkušena in potrošna.