I Java, SOLIDE principper er en objektorienteret tilgang, der anvendes til softwarestrukturdesign. Det konceptualiseres af Robert C. Martin (også kendt som Onkel Bob). Disse fem principper har ændret verden af ​​objektorienteret programmering, og også ændret måden at skrive software på. Det sikrer også, at softwaren er modulopbygget, let at forstå, fejlfinde og refactor. I dette afsnit vil vi diskutere SOLIDE principper i Java med det rigtige eksempel .

Ordet SOLID akronym for:

• Single Responsibility Principle (SRP)
• Åbent-lukket princip (OCP)
• Liskov substitutionsprincippet (LSP)
• Interface Segregation Principle (ISP)
• Afhængighedsinversionsprincip (DIP)

Lad os forklare principperne en efter en i detaljer.

simpel datoformater i java

Enkelt ansvarsprincip

Det fremgår af princippet om et enkelt ansvar hver Java-klasse skal udføre en enkelt funktionalitet . Implementering af flere funktioner i en enkelt klasse mashup koden, og hvis der kræves ændringer, kan det påvirke hele klassen. Det præciserer koden, og koden kan nemt vedligeholdes. Lad os forstå princippet om enkelt ansvar gennem et eksempel.

Formode, Studerende er en klasse med tre metoder, nemlig printDetails(), calculatePercentage(), og addStudent(). Derfor har elevklassen tre ansvarsområder for at udskrive detaljer om elever, beregne procenter og database. Ved at bruge enkeltansvarsprincippet kan vi adskille disse funktionaliteter i tre separate klasser for at opfylde princippets mål.

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

Ovenstående kodestykke overtræder princippet om enkelt ansvar. For at nå målet med princippet bør vi implementere en separat klasse, der kun udfører en enkelt funktionalitet.

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

Derfor har vi opnået målet med enkeltansvarsprincippet ved at opdele funktionaliteten i tre separate klasser.

Åbent-lukket princip

Applikationen eller modulet enheder metoder, funktioner, variabler osv. Åben-lukket-princippet siger, at i henhold til nye krav modulet skal være åbent for forlængelse, men lukket for modifikation. Udvidelsen giver os mulighed for at implementere ny funktionalitet til modulet. Lad os forstå princippet gennem et eksempel.

Formode, VehicleInfo er en klasse, og den har metoden køretøjsnummer() der returnerer køretøjets nummer.

VehicleInfo.java

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

Hvis vi ønsker at tilføje en anden underklasse ved navn Truck, tilføjer vi blot en mere if-sætning, der overtræder åben-lukket-princippet. Den eneste måde at tilføje underklassen og opnå det principielle mål ved at tilsidesætte køretøjsnummer() metode, som vi har vist nedenfor.

delvist afledt symbol latex

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

På samme måde kan vi tilføje flere køretøjer ved at lave en anden underklasse, der strækker sig fra køretøjsklassen. tilgangen vil ikke påvirke den eksisterende applikation.

Liskov Substitutionsprincip

Liskov Substitutionsprincippet (LSP) blev indført af Barbara Liskov . Det gælder for arv på en sådan måde, at afledte klasser skal være fuldstændig substituerbare for deres basisklasser . Med andre ord, hvis klasse A er en undertype af klasse B, så burde vi være i stand til at erstatte B med A uden at afbryde programmets opførsel.

Den udvider åben-luk-princippet og fokuserer også på adfærden af ​​en superklasse og dens undertyper. Vi bør designe klasserne for at bevare ejendommen, medmindre vi har en stærk grund til at gøre andet. Lad os forstå princippet gennem et eksempel.

vælg fra flere tabeller i sql

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

Ovenstående klasser overtrådte Liskov substitutionsprincippet, fordi StudentBMI-klassen har ekstra begrænsninger, dvs. højde og vægt, der skal være ens. Derfor kan Student-klassen (basisklassen) ikke erstattes af StudentBMI-klassen (afledt klasse).

Derfor kan udskiftning af klassen Student med StudentBMI-klassen resultere i uventet adfærd.

Interfacesegregationsprincip

Princippet siger, at de større grænseflader opdeles i mindre. Fordi implementeringsklasserne kun bruger de metoder, der kræves. Vi skal ikke tvinge klienten til at bruge de metoder, de ikke ønsker at bruge.

Målet med grænsefladeadskillelsesprincippet ligner princippet om enkelt ansvar. Lad os forstå princippet gennem et eksempel.

Antag, at vi har oprettet en grænseflade ved navn Konvertering har tre metoder intToDouble(), intToChar(), og charToString() .

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

Ovenstående grænseflade har tre metoder. Hvis vi kun vil bruge en metode intToChar(), har vi ikke noget valg til at implementere den enkelte metode. For at overvinde problemet giver princippet os mulighed for at opdele grænsefladen i tre separate.

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

Nu kan vi kun bruge den metode, der kræves. Antag, at vi vil konvertere heltal til dobbelt og tegn til streng, så vil vi kun bruge metoderne intToDouble() og charToString().

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

Afhængighedsinversionsprincip

Princippet siger, at vi skal bruge abstraktion (abstrakte klasser og grænseflader) i stedet for konkrete implementeringer. Moduler på højt niveau bør ikke afhænge af modulet på lavt niveau, men begge bør afhænge af abstraktionen. Fordi abstraktionen ikke afhænger af detaljer, men detaljen afhænger af abstraktion. Det afkobler softwaren. Lad os forstå princippet gennem et eksempel.

 public class WindowsMachine { //functionality } 

Det er værd, hvis vi ikke har tastatur og mus til at arbejde på Windows. For at løse dette problem opretter vi en konstruktør af klassen og tilføjer forekomsterne af tastaturet og skærmen. Efter tilføjelse af forekomsterne ser klassen sådan ud:

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

Nu kan vi arbejde på Windows-maskinen ved hjælp af et tastatur og en mus. Men vi står stadig over for problemet. Fordi vi har koblet de tre klasser tæt sammen ved at bruge det nye søgeord. Det er svært at teste klassens Windows-maskine.

For at gøre koden løst koblet afkobler vi WindowsMachine fra tastaturet ved at bruge tastaturgrænsefladen og dette nøgleord.

Keyboard.java

java læse csv-fil

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

I ovenstående kode har vi brugt afhængighedsinjektionen til at tilføje tastaturafhængigheden i WindowsMachine-klassen. Derfor har vi afkoblet klasserne.

Hvorfor skal vi bruge SOLIDE principper?

• Det reducerer afhængighederne, så en kodeblok kan ændres uden at påvirke de andre kodeblokke.
• Principperne har til formål at gøre design lettere, forståeligt.
• Ved at bruge principperne er systemet vedligeholdeligt, testbart, skalerbart og genanvendeligt.
• Det undgår softwarens dårlige design.

Næste gang, når du designer software, skal du huske på disse fem principper. Ved at anvende disse principper vil koden være meget mere klar, testbar og brugbar.