I Java, SOLIDE prinsipper er en objektorientert tilnærming som brukes til programvarestrukturdesign. Det er konseptualisert av Robert C. Martin (også kjent som onkel Bob). Disse fem prinsippene har endret verden av objektorientert programmering, og også endret måten å skrive programvare på. Det sikrer også at programvaren er modulær, lett å forstå, feilsøke og refactor. I denne delen vil vi diskutere SOLIDE prinsipper i Java med riktig eksempel .
Ordet SOLID akronym for:
- Single Responsibility Principle (SRP)
- Åpent lukket prinsipp (OCP)
- Liskov Substitusjonsprinsipp (LSP)
- Interface Segregation Principle (ISP)
- Dependency Inversion Principle (DIP)
La oss forklare prinsippene en etter en i detalj.
enkel datoformater i java
Enkelt ansvarsprinsipp
Enkeltansvarsprinsippet sier det hver Java-klasse må utføre en enkelt funksjonalitet . Implementering av flere funksjoner i en enkelt klasse blander koden, og hvis det er nødvendig med endringer, kan det påvirke hele klassen. Den presiserer koden og koden kan lett vedlikeholdes. La oss forstå enkeltansvarsprinsippet gjennom et eksempel.
Anta, Student er en klasse som har tre metoder, nemlig printDetails(), calculatePercentage(), og addStudent(). Derfor har studentklassen tre ansvarsområder for å skrive ut detaljene til studentene, beregne prosenter og database. Ved å bruke enkeltansvarsprinsippet kan vi dele disse funksjonalitetene inn i tre separate klasser for å oppfylle målet med prinsippet.
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 } } Kodebiten ovenfor bryter med enkeltansvarsprinsippet. For å oppnå målet med prinsippet bør vi implementere en egen klasse som kun utfører en enkelt funksjonalitet.
Student.java
public class Student { public void addStudent(); { //functionality of the method } } PrintStudentDetails.java
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } Prosent.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } Derfor har vi oppnådd målet med enkeltansvarsprinsippet ved å dele funksjonaliteten i tre separate klasser.
Åpent-lukket prinsipp
Applikasjonen eller modulen entiteter metodene, funksjonene, variablene osv. Åpen-lukket-prinsippet sier at i henhold til nye krav modulen skal være åpen for utvidelse, men lukket for modifikasjon. Utvidelsen lar oss implementere ny funksjonalitet til modulen. La oss forstå prinsippet gjennom et eksempel.
Anta, VehicleInfo er en klasse og den har metoden kjøretøynummer() som returnerer kjøretøynummeret.
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 å legge til en annen underklasse som heter Truck, legger vi ganske enkelt til en if-setning til som bryter med åpent-lukket-prinsippet. Den eneste måten å legge til underklassen og oppnå prinsippmålet ved å overstyre kjøretøynummer() metode, som vi har vist nedenfor.
alfa beta beskjæring eksempel
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åte kan vi legge til flere kjøretøy ved å lage en annen underklasse som strekker seg fra kjøretøyklassen. tilnærmingen vil ikke påvirke den eksisterende søknaden.
Liskov Substitusjonsprinsipp
Liskov Substitusjonsprinsippet (LSP) ble introdusert av Barbara Liskov . Det gjelder arv på en slik måte at avledede klasser må være fullstendig substituerbare for sine basisklasser . Med andre ord, hvis klasse A er en undertype av klasse B, bør vi kunne erstatte B med A uten å avbryte oppførselen til programmet.
Den utvider åpen-lukk-prinsippet og fokuserer også på oppførselen til en superklasse og dens undertyper. Vi bør utforme klassene for å bevare eiendommen med mindre vi har en sterk grunn til å gjøre noe annet. La oss forstå prinsippet gjennom et eksempel.
hvordan åpne en fil med java
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); } } Klassene ovenfor brøt med Liskov-substitusjonsprinsippet fordi StudentBMI-klassen har ekstra begrensninger, dvs. høyde og vekt som må være den samme. Derfor kan ikke Student-klassen (grunnklassen) erstattes av StudentBMI-klassen (avledet klasse).
Derfor kan det å erstatte klassen Student med StudentBMI-klassen resultere i uventet oppførsel.
Grensesnittsegregeringsprinsipp
Prinsippet sier at de større grensesnittene deler seg opp i mindre. Fordi implementeringsklassene bare bruker metodene som kreves. Vi skal ikke tvinge klienten til å bruke metodene de ikke ønsker å bruke.
Målet med grensesnittsegregeringsprinsippet ligner enkeltansvarsprinsippet. La oss forstå prinsippet gjennom et eksempel.
Anta at vi har laget et grensesnitt kalt Omdannelse har tre metoder intToDouble(), intToChar(), og charToString() .
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } Grensesnittet ovenfor har tre metoder. Hvis vi kun vil bruke en metode intToChar(), har vi ikke noe valg for å implementere enkeltmetoden. For å overvinne problemet lar prinsippet oss dele grensesnittet i tre separate.
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } Nå kan vi bare bruke metoden som kreves. Anta at vi ønsker å konvertere heltall til dobbel og tegn til streng, da vil vi bare bruke metodene intToDouble() og charToString().
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } Avhengighetsinversjonsprinsipp
Prinsippet sier at vi må bruke abstraksjon (abstrakte klasser og grensesnitt) i stedet for konkrete implementeringer. Høynivåmoduler bør ikke avhenge av lavnivåmodulen, men begge bør avhenge av abstraksjonen. Fordi abstraksjonen ikke er avhengig av detaljer, men detaljen avhenger av abstraksjon. Den kobler fra programvaren. La oss forstå prinsippet gjennom et eksempel.
public class WindowsMachine { //functionality } Det er verdt, hvis vi ikke har tastatur og mus til å fungere på Windows. For å løse dette problemet oppretter vi en konstruktør av klassen og legger til forekomstene av tastaturet og skjermen. Etter å ha lagt til forekomstene, ser klassen slik ut:
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 } } Nå kan vi jobbe på Windows-maskinen ved hjelp av tastatur og mus. Men vi står fortsatt overfor problemet. Fordi vi har koblet de tre klassene tett sammen ved å bruke det nye nøkkelordet. Det er vanskelig å teste klassens Windows-maskin.
For å gjøre koden løst koblet, kobler vi WindowsMachine fra tastaturet ved å bruke tastaturgrensesnittet og dette nøkkelordet.
Keyboard.java
tilpasset unntak i 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; } } I koden ovenfor har vi brukt avhengighetsinjeksjonen for å legge til tastaturavhengigheten i WindowsMachine-klassen. Derfor har vi frakoblet klassene.
Hvorfor skal vi bruke SOLIDE prinsipper?
- Det reduserer avhengighetene slik at en kodeblokk kan endres uten å påvirke de andre kodeblokkene.
- Prinsippene skal gjøre design enklere og forståelig.
- Ved å bruke prinsippene er systemet vedlikeholdbart, testbart, skalerbart og gjenbrukbart.
- Det unngår den dårlige utformingen av programvaren.
Neste gang du designer programvare, husk disse fem prinsippene. Ved å anvende disse prinsippene vil koden være mye mer oversiktlig, testbar og brukbar.