v Javě, SOLID principy jsou objektově orientovaný přístup, který se používá při návrhu struktury softwaru. Je konceptualizován podle Robert C. Martin (také známý jako strýček Bob). Těchto pět principů změnilo svět objektově orientovaného programování a také změnilo způsob psaní softwaru. Zajišťuje také, že software je modulární, snadno srozumitelný, laditelný a refaktorovatelný. V této části budeme diskutovat Principy SOLID v Javě se správným příkladem .
Zkratka slova SOLID pro:
- Princip jednotné odpovědnosti (SRP)
- Otevřený-uzavřený princip (OCP)
- Liskovův substituční princip (LSP)
- Interface Segregation Principle (ISP)
- Princip inverze závislosti (DIP)
Pojďme si principy jeden po druhém podrobně vysvětlit.
Princip jednotné odpovědnosti
Princip jednotné odpovědnosti to říká každá třída Java musí provádět jedinou funkci . Implementace více funkcí v jedné třídě rozmixuje kód a pokud je nutná jakákoliv úprava, může ovlivnit celou třídu. Upřesňuje kód a kód lze snadno udržovat. Pojďme pochopit princip jediné odpovědnosti na příkladu.
Předpokládat, Student je třída, která má tři metody, jmenovitě printDetails(), vypočítatPercentage(), a addStudent(). Třída Student má tedy tři povinnosti vytisknout podrobnosti o studentech, vypočítat procenta a vytvořit databázi. Použitím principu jediné odpovědnosti můžeme tyto funkce rozdělit do tří samostatných tříd, abychom splnili cíl principu.
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 } } Výše uvedený fragment kódu porušuje zásadu jediné odpovědnosti. Abychom dosáhli cíle principu, měli bychom implementovat samostatnou třídu, která vykonává pouze jedinou funkci.
Student.java
public class Student { public void addStudent(); { //functionality of the method } } PrintStudentDetails.java
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } Procento.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } Tím jsme dosáhli cíle principu jediné odpovědnosti rozdělením funkčnosti do tří samostatných tříd.
Princip otevřený-uzavřený
Aplikace nebo modul jsou entitami metod, funkcí, proměnných atd. Princip otevřená-uzavřený říká, že podle nových požadavků modul by měl být otevřený pro rozšíření, ale uzavřený pro úpravy. Rozšíření nám umožňuje implementovat do modulu nové funkce. Pojďme pochopit princip na příkladu.
Předpokládat, Informace o vozidle je třída a má metodu vehicleNumber() která vrátí číslo vozidla.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } Pokud chceme přidat další podtřídu s názvem Truck, jednoduše přidáme ještě jeden příkaz if, který porušuje princip otevřeno-uzavřeno. Jediný způsob, jak přidat podtřídu a dosáhnout cíle principu přepsáním podtřídy vehicleNumber() metodou, jak jsme si ukázali níže.
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(); } Podobně můžeme přidat další vozidla vytvořením další podtřídy rozšiřující se z třídy vozidel. přístup by neovlivnil stávající aplikaci.
Liskovův substituční princip
Liskovský substituční princip (LSP) zavedl Barbarou Liškovou . Na dědictví se vztahuje tak, že odvozené třídy musí být zcela nahraditelné svými základními třídami . Jinými slovy, pokud je třída A podtypem třídy B, pak bychom měli být schopni nahradit B za A, aniž bychom přerušili chování programu.
Rozšiřuje princip open-close a zaměřuje se také na chování nadtřídy a jejích podtypů. Třídy bychom měli navrhnout tak, aby byla zachována vlastnost, pokud nemáme pádný důvod udělat jinak. Pojďme pochopit princip na příkladu.
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); } } Výše uvedené třídy porušily princip Liskovovy substituce, protože třída StudentBMI má další omezení, tj. výšku a váhu, které musí být stejné. Třídu Student (základní třídu) proto nelze nahradit třídou StudentBMI (odvozená třída).
Proto nahrazení třídy Student třídou StudentBMI může vést k neočekávanému chování.
Princip segregace rozhraní
Princip říká, že větší rozhraní se rozdělí na menší. Protože implementační třídy používají pouze metody, které jsou vyžadovány. Neměli bychom klienta nutit používat metody, které nechce používat.
Cíl principu segregace rozhraní je podobný principu jediné odpovědnosti. Pojďme pochopit princip na příkladu.
Předpokládejme, že jsme vytvořili rozhraní s názvem Konverze mající tři metody intToDouble(), intToChar(), a charToString() .
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } Výše uvedené rozhraní má tři způsoby. Pokud chceme použít pouze metodu intToChar(), nemáme jinou možnost implementovat jedinou metodu. Abychom problém překonali, princip nám umožňuje rozdělit rozhraní na tři samostatné.
fronta v Javě
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } Nyní můžeme použít pouze metodu, která je požadována. Předpokládejme, že chceme převést celé číslo na double a znak na řetězec, pak použijeme pouze metody intToDouble() a charToString().
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } Princip inverze závislosti
Princip říká, že místo konkrétních implementací musíme používat abstrakci (abstraktní třídy a rozhraní). Moduly vysoké úrovně by neměly záviset na modulu nízké úrovně, ale oba by měly záviset na abstrakci. Protože abstrakce nezávisí na detailu, ale detail závisí na abstrakci. Odděluje software. Pojďme pochopit princip na příkladu.
public class WindowsMachine { //functionality } Vyplatí se, pokud nemáme klávesnici a myš pracovat na Windows. Abychom tento problém vyřešili, vytvoříme konstruktor třídy a přidáme instance klávesnice a monitoru. Po přidání instancí vypadá třída takto:
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 } } Nyní můžeme pracovat na počítači s Windows pomocí klávesnice a myši. Ale stále čelíme problému. Protože jsme pomocí klíčového slova new spojili tyto tři třídy dohromady. Je těžké otestovat stroj třídy Windows.
Aby byl kód volně propojený, oddělíme WindowsMachine od klávesnice pomocí rozhraní klávesnice a tohoto klíčového slova.
Klávesnice.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; } } Ve výše uvedeném kódu jsme použili vložení závislosti k přidání závislosti klávesnice do třídy WindowsMachine. Proto jsme třídy oddělili.
Proč bychom měli používat principy SOLID?
- Snižuje závislosti, takže blok kódu lze změnit bez ovlivnění ostatních bloků kódu.
- Principy určené k tomu, aby byl design jednodušší a srozumitelnější.
- Použitím principů je systém udržovatelný, testovatelný, škálovatelný a opakovaně použitelný.
- Vyhnete se tak špatnému designu softwaru.
Až budete příště navrhovat software, mějte na paměti těchto pět zásad. Aplikací těchto principů bude kód mnohem přehlednější, testovatelnější a postradatelnější.