Op Java, SOLIDE principes zijn een objectgeoriënteerde benadering die wordt toegepast op het ontwerp van softwarestructuren. Het is geconceptualiseerd door Robert C. Martin (ook bekend als oom Bob). Deze vijf principes hebben de wereld van objectgeoriënteerd programmeren veranderd, en ook de manier waarop software wordt geschreven. Het zorgt er ook voor dat de software modulair, gemakkelijk te begrijpen, te debuggen en te refactoren is. In deze sectie zullen we bespreken SOLID-principes in Java met het juiste voorbeeld .

Het woord SOLID is een afkorting voor:

• Principe van enkele verantwoordelijkheid (SRP)
• Open-gesloten principe (OCP)
• Liskov-substitutieprincipe (LSP)
• Interface-segregatieprincipe (ISP)
• Afhankelijkheidsinversieprincipe (DIP)

Laten we de principes één voor één in detail uitleggen.

Principe van één verantwoordelijkheid

Het principe van enkele verantwoordelijkheid stelt dat elke Java-klasse moet één functionaliteit uitvoeren . Implementatie van meerdere functionaliteiten in één klasse mixt de code en als er een wijziging nodig is, kan dit gevolgen hebben voor de hele klasse. Het specificeert de code en de code kan gemakkelijk worden onderhouden. Laten we het principe van één verantwoordelijkheid begrijpen aan de hand van een voorbeeld.

Veronderstellen, Student is een klasse met drie methoden namelijk printDetails(), berekenPercentage(), En addStudent(). Daarom heeft de klasse Student drie verantwoordelijkheden: het afdrukken van de gegevens van studenten, het berekenen van percentages en het maken van een database. Door het principe van enkele verantwoordelijkheid te gebruiken, kunnen we deze functionaliteiten in drie afzonderlijke klassen verdelen om het doel van het principe te verwezenlijken.

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

Het bovenstaande codefragment is in strijd met het beginsel van individuele verantwoordelijkheid. Om het doel van het principe te bereiken, moeten we een aparte klasse implementeren die slechts één functionaliteit uitvoert.

Student.java

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

PrintStudentDetails.java

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

Percentage.java

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

Daarom hebben we het doel van het principe van enkele verantwoordelijkheid bereikt door de functionaliteit in drie afzonderlijke klassen te verdelen.

Open-gesloten principe

De applicatie of module omvat de methoden, functies, variabelen, etc. Het open-gesloten principe stelt dat volgens nieuwe eisen de module moet open zijn voor uitbreiding, maar gesloten voor wijziging. Met de uitbreiding kunnen we nieuwe functionaliteit in de module implementeren. Laten we het principe begrijpen aan de hand van een voorbeeld.

Veronderstellen, Voertuiginfo is een klasse en heeft de methode Voertuignummer() die het voertuignummer retourneert.

VoertuigInfo.java

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

Als we nog een subklasse met de naam Truck willen toevoegen, voegen we eenvoudigweg nog een if-instructie toe die in strijd is met het open-gesloten-principe. De enige manier om de subklasse toe te voegen en het principedoel te bereiken door de Voertuignummer() methode, zoals we hieronder hebben laten zien.

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

Op dezelfde manier kunnen we meer voertuigen toevoegen door een andere subklasse te maken die zich uitstrekt van de voertuigklasse. de aanpak zou geen invloed hebben op de bestaande toepassing.

Liskov-substitutieprincipe

Het Liskov-substitutieprincipe (LSP) werd geïntroduceerd door Barbara Liskov . Het is op zodanige wijze van toepassing op de erfenis dat de afgeleide klassen moeten volledig vervangbaar zijn voor hun basisklassen . Met andere woorden: als klasse A een subtype is van klasse B, dan zouden we B door A moeten kunnen vervangen zonder het gedrag van het programma te onderbreken.

Het breidt het open-dicht-principe uit en richt zich ook op het gedrag van een superklasse en zijn subtypen. We moeten de klassen zo ontwerpen dat het eigendom behouden blijft, tenzij we een goede reden hebben om anders te doen. Laten we het principe begrijpen aan de hand van een voorbeeld.

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

De bovenstaande klassen schonden het Liskov-substitutieprincipe omdat de StudentBMI-klasse extra beperkingen heeft, d.w.z. lengte en gewicht die hetzelfde moeten zijn. Daarom kan de Student-klasse (basisklasse) niet worden vervangen door de StudentBMI-klasse (afgeleide klasse).

Daarom kan het vervangen van de klasse Student door de klasse StudentBMI tot onverwacht gedrag leiden.

Principe van interface-segregatie

Het principe stelt dat de grotere interfaces zich opsplitsen in kleinere. Omdat de implementatieklassen alleen de methoden gebruiken die vereist zijn. We moeten de cliënt niet dwingen methoden te gebruiken die hij niet wil gebruiken.

Het doel van het interfacesegregatieprincipe is vergelijkbaar met het principe van enkele verantwoordelijkheid. Laten we het principe begrijpen aan de hand van een voorbeeld.

Stel dat we een interface hebben gemaakt met de naam Conversie drie methoden hebben intToDouble(), intToChar(), En charToString() .

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

De bovenstaande interface heeft drie methoden. Als we alleen een methode intToChar() willen gebruiken, hebben we geen keus om de enkele methode te implementeren. Om dit probleem op te lossen, stelt het principe ons in staat de interface in drie afzonderlijke interfaces te splitsen.

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

Nu kunnen we alleen de vereiste methode gebruiken. Stel dat we het gehele getal naar dubbel en het teken naar string willen converteren, dan gebruiken we alleen de methoden intToDouble() En charToString().

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

Afhankelijkheidsinversieprincipe

Het principe stelt dat we abstractie (abstracte klassen en interfaces) moeten gebruiken in plaats van concrete implementaties. Modules op hoog niveau mogen niet afhankelijk zijn van de module op laag niveau, maar beide moeten afhankelijk zijn van de abstractie. Omdat de abstractie niet afhankelijk is van details, maar de details van abstractie. Het ontkoppelt de software. Laten we het principe begrijpen aan de hand van een voorbeeld.

 public class WindowsMachine { //functionality } 

Het is de moeite waard als we geen toetsenbord en muis hebben om op Windows te werken. Om dit probleem op te lossen, maken we een constructor van de klasse en voegen we de instanties van het toetsenbord en de monitor toe. Na het toevoegen van de instances ziet de klasse er als volgt uit:

 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 kunnen we op de Windows-machine werken met behulp van een toetsenbord en muis. Maar we worden nog steeds met het probleem geconfronteerd. Omdat we de drie klassen nauw aan elkaar hebben gekoppeld door het nieuwe trefwoord te gebruiken. Het is moeilijk om de klasse Windows-machine te testen.

Om de code losjes gekoppeld te maken, ontkoppelen we de WindowsMachine van het toetsenbord door de toetsenbordinterface en dit trefwoord te gebruiken.

inttostr java

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

In de bovenstaande code hebben we de afhankelijkheidsinjectie gebruikt om de toetsenbordafhankelijkheid toe te voegen aan de WindowsMachine-klasse. Daarom hebben we de klassen ontkoppeld.

Waarom zouden we SOLID-principes moeten gebruiken?

• Het vermindert de afhankelijkheden, zodat een codeblok kan worden gewijzigd zonder de andere codeblokken te beïnvloeden.
• De principes bedoeld om het ontwerp eenvoudiger en begrijpelijker te maken.
• Door gebruik te maken van de principes is het systeem onderhoudbaar, testbaar, schaalbaar en herbruikbaar.
• Het vermijdt het slechte ontwerp van de software.

Houd de volgende keer dat u software ontwerpt deze vijf principes in gedachten. Door deze principes toe te passen, zal de code veel duidelijker, testbaarder en vervangbaarder zijn.