Java, SOLID principai yra į objektą orientuotas metodas, taikomas kuriant programinės įrangos struktūrą. Jį konceptualizuoja Robertas C. Martinas (taip pat žinomas kaip dėdė Bobas). Šie penki principai pakeitė objektinio programavimo pasaulį, taip pat pakeitė programinės įrangos rašymo būdą. Tai taip pat užtikrina, kad programinė įranga būtų modulinė, lengvai suprantama, derinama ir atnaujinama. Šiame skyriuje aptarsime SOLID principai Java su tinkamu pavyzdžiu .

paleisti scenarijus Linux sistemoje

Žodžio SOLID akronimas:

• Vienos atsakomybės principas (SRP)
• Atviras uždaras principas (OCP)
• Liskovo pakeitimo principas (LSP)
• Sąsajos atskyrimo principas (IPT)
• Priklausomybės inversijos principas (DIP)

Išsamiai paaiškinkime principus po vieną.

Vienos atsakomybės principas

Vieningos atsakomybės principas tai teigia kiekviena Java klasė turi atlikti vieną funkciją . Kelių funkcijų įgyvendinimas vienoje klasėje sumaišo kodą ir, jei reikia kokių nors modifikacijų, gali turėti įtakos visai klasei. Tai tikslus kodas ir kodą galima lengvai prižiūrėti. Supraskime vienos atsakomybės principą per pavyzdį.

Tarkime, Studentas yra klasė, turinti tris metodus printDetails (), apskaičiuoti procentą (), ir addStudent(). Taigi, Mokinių klasė turi tris pareigas spausdinti informaciją apie mokinius, apskaičiuoti procentus ir duomenų bazę. Naudodami vienos atsakomybės principą, šias funkcijas galime atskirti į tris atskiras klases, kad būtų pasiektas principo tikslas.

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

Aukščiau pateiktas kodo fragmentas pažeidžia vienos atsakomybės principą. Norėdami pasiekti principo tikslą, turėtume įdiegti atskirą klasę, kuri atlieka tik vieną funkcionalumą.

Studentas.java

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

PrintStudentDetails.java

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

Procentai.java

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

Taigi, išskirstę funkcionalumą į tris atskiras klases, pasiekėme vienos atsakomybės principo tikslą.

Atviro-uždarymo principas

Programa ar modulis pateikia metodus, funkcijas, kintamuosius ir pan. Atviro-uždarymo principas teigia, kad pagal naujus reikalavimus modulis turi būti atidarytas pratęsimui, bet uždarytas modifikavimui. Plėtinys leidžia įdiegti naujas modulio funkcijas. Supraskime principą per pavyzdį.

Tarkime, Transporto priemonės informacija yra klasė ir ji turi metodą transporto priemonės numeris () kuris grąžina automobilio numerį.

VehicleInfo.java

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

Jei norime pridėti kitą poklasį pavadinimu Truck, tiesiog pridedame dar vieną if teiginį, kuris pažeidžia atviro-uždarymo principą. Vienintelis būdas pridėti poklasį ir pasiekti principinį tikslą, nepaisydami transporto priemonės numeris () metodas, kaip parodyta toliau.

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

Taip pat galime pridėti daugiau transporto priemonių, sukurdami kitą poklasį, kuris tęsiasi iš transporto priemonių klasės. šis metodas neturėtų įtakos esamai programai.

Liskovo pakeitimo principas

Liskovo pakeitimo principą (LSP) pristatė Barbara Liskova . Jis taikomas paveldėjimui tokiu būdu, kad išvestinės klasės turi būti visiškai pakeistos savo bazinėmis klasėmis . Kitaip tariant, jei A klasė yra B klasės potipis, mes turėtume turėti galimybę B pakeisti A nepertraukdami programos veikimo.

Jis išplečia atviro-uždarymo principą ir taip pat sutelkia dėmesį į superklasės ir jos potipių elgesį. Turėtume sukurti klases taip, kad būtų išsaugotas turtas, nebent turime rimtų priežasčių elgtis kitaip. Supraskime principą per pavyzdį.

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

Minėtos klasės pažeidė Liskovo pakeitimo principą, nes StudentBMI klasė turi papildomų apribojimų, ty ūgio ir svorio, kurie turi būti vienodi. Todėl Studento klasė (bazinė klasė) negali būti pakeista StudentBMI klase (išvestinė klasė).

Taigi, klasę Studentas pakeitus StudentBMI klase, gali atsirasti netikėtas elgesys.

Sąsajos atskyrimo principas

Principas teigia, kad didesnės sąsajos suskaidomos į mažesnes. Kadangi diegimo klasėse naudojami tik reikalingi metodai. Neturėtume versti kliento naudoti metodus, kurių jis nenori naudoti.

Sąsajos atskyrimo principo tikslas yra panašus į vienos atsakomybės principą. Supraskime principą per pavyzdį.

Tarkime, sukūrėme sąsają pavadinimu Konversija turintys tris metodus intToDouble(), intToChar(), ir charToString() .

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

Aukščiau pateikta sąsaja turi tris būdus. Jei norime naudoti tik metodą intToChar(), neturime pasirinkimo įgyvendinti vieną metodą. Norėdami išspręsti problemą, šis principas leidžia padalyti sąsają į tris atskiras.

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

Dabar galime naudoti tik reikiamą metodą. Tarkime, kad sveikąjį skaičių norime konvertuoti į dvigubą, o simbolį į eilutę, tada naudosime tik metodus intToDouble() ir charToString().

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

Priklausomybės inversijos principas

Principas teigia, kad vietoj konkrečių įgyvendinimų turime naudoti abstrakciją (abstrakčias klases ir sąsajas). Aukšto lygio moduliai neturėtų priklausyti nuo žemo lygio modulio, bet abu turėtų priklausyti nuo abstrakcijos. Nes abstrakcija nepriklauso nuo detalių, o detalė priklauso nuo abstrakcijos. Jis atsieja programinę įrangą. Supraskime principą per pavyzdį.

 public class WindowsMachine { //functionality } 

Jei neturime klaviatūros ir pelės, verta dirbti su „Windows“. Norėdami išspręsti šią problemą, sukuriame klasės konstruktorių ir pridedame klaviatūros ir monitoriaus egzempliorius. Pridėjus atvejus, klasė atrodo taip:

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

Dabar galime dirbti su „Windows“ kompiuteriu naudodami klaviatūrą ir pelę. Bet vis tiek susiduriame su problema. Kadangi mes glaudžiai sujungėme tris klases, naudodami naują raktinį žodį. Sunku išbandyti klasės „Windows“ mašiną.

Kad kodas būtų laisvai susietas, atjungiame WindowsMachine nuo klaviatūros naudodami klaviatūros sąsają ir šį raktinį žodį.

Klaviatūra.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; } } 

Aukščiau pateiktame kode naudojome priklausomybės injekciją, kad įtrauktume klaviatūros priklausomybę „WindowsMachine“ klasėje. Todėl klases atsiejome.

Kodėl turėtume naudoti SOLID principus?

• Tai sumažina priklausomybes, kad būtų galima pakeisti kodo bloką nepažeidžiant kitų kodo blokų.
• Principai skirti padaryti dizainą lengvesnį, suprantamesnį.
• Naudojant šiuos principus, sistema yra prižiūrima, išbandoma, keičiama ir pakartotinai naudojama.
• Taip išvengiama blogo programinės įrangos dizaino.

Kitą kartą kurdami programinę įrangą nepamirškite šių penkių principų. Taikant šiuos principus, kodas bus daug aiškesnis, patikrinamas ir lengviau naudojamas.