Java valodā, SOLID principi ir uz objektu orientēta pieeja, kas tiek izmantota programmatūras struktūras projektēšanā. To konceptualizē Roberts C. Mārtins (pazīstams arī kā onkulis Bobs). Šie pieci principi ir mainījuši objektorientētās programmēšanas pasauli, kā arī mainījuši programmatūras rakstīšanas veidu. Tas arī nodrošina, ka programmatūra ir modulāra, viegli saprotama, atkļūdojama un pārveidojama. Šajā sadaļā mēs apspriedīsim SOLID principi Java ar atbilstošu piemēru .

Vārda SOLID akronīms:

• Vienas atbildības princips (SRP)
• Atvērtais-slēgtais princips (OCP)
• Liskova aizstāšanas princips (LSP)
• Interfeisa segregācijas princips (ISP)
• Atkarības inversijas princips (DIP)

Sīkāk paskaidrosim principus pa vienam.

Vienas atbildības princips

To nosaka vienotās atbildības princips katrai Java klasei ir jāveic viena funkcionalitāte . Vairāku funkciju ieviešana vienā klasē sajauc kodu un, ja nepieciešamas izmaiņas, var ietekmēt visu klasi. Tas precizē kodu, un kodu var viegli uzturēt. Izpratīsim vienotās atbildības principu, izmantojot piemēru.

norādes c

Pieņemsim, Students ir klase, kurā ir trīs metodes printDetails(), aprēķināt procentus(), un addStudent(). Tādējādi studentu klasei ir trīs pienākumi, lai izdrukātu informāciju par studentiem, aprēķinātu procentus un datubāzi. Izmantojot vienotās atbildības principu, mēs varam sadalīt šīs funkcijas trīs atsevišķās klasēs, lai sasniegtu principa mērķi.

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 } } 

Iepriekš minētais koda fragments pārkāpj vienotās atbildības principu. Lai sasniegtu principa mērķi, mums ir jāievieš atsevišķa klase, kas veic tikai vienu funkcionalitāti.

Student.java

 public class Student { public void addStudent(); { //functionality of the method } } 

PrintStudentDetails.java

 public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } 

Procenti.java

 public class Percentage { public void calculatePercentage(); { //functionality of the method } } 

Tādējādi esam sasnieguši vienotās atbildības principa mērķi, sadalot funkcionalitāti trīs atsevišķās klasēs.

Atvērtā-slēgtā princips

Lietojumprogramma vai modulis entītē metodes, funkcijas, mainīgos utt. Atvērtā-slēgtā princips nosaka, ka saskaņā ar jaunām prasībām modulim jābūt atvērtam paplašināšanai, bet aizvērtam modifikācijai. Paplašinājums ļauj mums ieviest jaunu funkcionalitāti modulī. Izpratīsim principu, izmantojot piemēru.

Pieņemsim, Transportlīdzekļa informācija ir klase, un tai ir metode transportlīdzekļa numurs() kas atgriež transportlīdzekļa numuru.

VehicleInfo.java

 public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } 

Ja mēs vēlamies pievienot vēl vienu apakšklasi ar nosaukumu Truck, mēs vienkārši pievienojam vēl vienu if paziņojumu, kas pārkāpj atvērtā-slēgtā principu. Vienīgais veids, kā pievienot apakšklasi un sasniegt principiālo mērķi, ignorējot transportlīdzekļa numurs() metodi, kā mēs esam parādījuši zemāk.

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(); } 

Tāpat mēs varam pievienot vairāk transportlīdzekļu, izveidojot vēl vienu apakšklasi, kas paplašina transportlīdzekļu klasi. pieeja neietekmētu esošo pieteikumu.

Liskova aizstāšanas princips

Liskova aizstāšanas principu (LSP) ieviesa Barbara Liskova . Tas attiecas uz mantojumu tādā veidā, ka atvasinātajām klasēm jābūt pilnībā aizvietojamām ar savām bāzes klasēm . Citiem vārdiem sakot, ja A klase ir B klases apakštips, tad mums vajadzētu būt iespējai aizstāt B ar A, nepārtraucot programmas darbību.

Tas paplašina atvēršanas-aizvēršanas principu un koncentrējas arī uz superklases un tās apakštipu uzvedību. Mums ir jāizstrādā klases, lai saglabātu īpašumu, ja vien mums nav nopietna iemesla rīkoties citādi. Izpratīsim principu, izmantojot piemēru.

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); } } 

Iepriekš minētās klases pārkāpa Liskova aizstāšanas principu, jo StudentBMI klasei ir papildu ierobežojumi, t.i., augumam un svaram ir jābūt vienādam. Tāpēc Studentu klasi (bāzes klasi) nevar aizstāt ar StudentBMI klasi (atvasinātu klasi).

Tādējādi klases Student aizstāšana ar StudentBMI klasi var izraisīt neparedzētu uzvedību.

Interfeisa segregācijas princips

Princips nosaka, ka lielākās saskarnes tiek sadalītas mazākās. Tā kā ieviešanas klasēs tiek izmantotas tikai nepieciešamās metodes. Mēs nedrīkstam piespiest klientu izmantot metodes, kuras viņš nevēlas izmantot.

Interfeisa segregācijas principa mērķis ir līdzīgs vienotās atbildības principam. Izpratīsim principu, izmantojot piemēru.

Pieņemsim, ka esam izveidojuši saskarni ar nosaukumu Pārvēršana kam ir trīs metodes intToDouble(), intToChar(), un charToString() .

 public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } 

Iepriekš minētajā saskarnē ir trīs metodes. Ja mēs vēlamies izmantot tikai metodi intToChar(), mums nav izvēles ieviest vienu metodi. Lai atrisinātu problēmu, šis princips ļauj mums sadalīt saskarni trīs atsevišķās.

kā piekļūt icloud fotoattēliem

 public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } 

Tagad mēs varam izmantot tikai nepieciešamo metodi. Pieņemsim, ka mēs vēlamies pārvērst veselu skaitli par dubultu un rakstzīmi par virkni, tad mēs izmantosim tikai metodes intToDouble() un charToString().

 public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } 

Atkarības inversijas princips

Princips nosaka, ka mums ir jāizmanto abstrakcija (abstraktas klases un saskarnes), nevis konkrētas implementācijas. Augsta līmeņa moduļiem nevajadzētu būt atkarīgiem no zemā līmeņa moduļa, bet abiem jābūt atkarīgiem no abstrakcijas. Jo abstrakcija nav atkarīga no detaļām, bet detaļas ir atkarīgas no abstrakcijas. Tas atvieno programmatūru. Izpratīsim principu, izmantojot piemēru.

 public class WindowsMachine { //functionality } 

Ja mums nav tastatūras un peles, ir vērts strādāt operētājsistēmā Windows. Lai atrisinātu šo problēmu, mēs izveidojam klases konstruktoru un pievienojam tastatūras un monitora gadījumus. Pēc gadījumu pievienošanas klase izskatās šādi:

 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 } } 

Tagad mēs varam strādāt ar Windows mašīnu ar tastatūras un peles palīdzību. Bet mēs joprojām saskaramies ar problēmu. Tā kā mēs esam cieši savienojuši trīs klases, izmantojot jauno atslēgvārdu. Ir grūti pārbaudīt klases Windows mašīnu.

Lai kods būtu brīvi savienots, mēs atvienojam WindowsMachine no tastatūras, izmantojot tastatūras saskarni un šo atslēgvārdu.

Keyboard.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; } } 

Iepriekš minētajā kodā mēs esam izmantojuši atkarības injekciju, lai pievienotu tastatūras atkarību WindowsMachine klasē. Tāpēc esam atdalījuši klases.

Kāpēc mums vajadzētu izmantot SOLID principus?

• Tas samazina atkarības, lai koda bloku varētu mainīt, neietekmējot citus koda blokus.
• Principi paredzēti, lai dizains būtu vieglāks, saprotamāks.
• Izmantojot principus, sistēma ir apkopjama, pārbaudāma, mērogojama un atkārtoti lietojama.
• Tas ļauj izvairīties no slikta programmatūras dizaina.

Nākamreiz, izstrādājot programmatūru, ņemiet vērā šos piecus principus. Piemērojot šos principus, kods būs daudz skaidrāks, pārbaudāmāks un iztērējamāks.