Java nyelven, SZILÁRD elvek egy objektum-orientált megközelítés, amelyet a szoftverstruktúra tervezésére alkalmaznak. A koncepciót a Robert C. Martin (más néven Bob bácsi). Ez az öt alapelv megváltoztatta az objektum-orientált programozás világát, és megváltoztatta a szoftverírás módját is. Azt is biztosítja, hogy a szoftver moduláris, könnyen érthető, hibakereső és újrafeldolgozható legyen. Ebben a részben megvitatjuk SOLID alapelvek Java-ban megfelelő példával .

A SOLID szó rövidítése:

• Egységes Felelősség Elve (SRP)
• Nyitott-zárt elv (OCP)
• Liskov helyettesítési elv (LSP)
• Interfész szegregációs elv (ISP)
• Függőség-inverziós elv (DIP)

Egyenként fejtsük ki részletesen az alapelveket.

Egységes felelősség elve

Az egységes felelősség elve azt mondja ki minden Java osztálynak egyetlen funkciót kell végrehajtania . Több funkció egyetlen osztályban való megvalósítása összekeveri a kódot, és ha bármilyen módosításra van szükség, az az egész osztályt érintheti. Pontosítja a kódot, és a kód könnyen karbantartható. Értsük meg egy példán keresztül az egyetlen felelősség elvét.

Tegyük fel, Diák egy olyan osztály, amelynek három metódusa van, nevezetesen printDetails(), számítsa százalék(), és addStudent(). Ezért a tanuló osztálynak három feladata van a tanulók adatainak kinyomtatásában, a százalékok kiszámításában és az adatbázisban. Az egységes felelősség elvének használatával ezeket a funkcionalitásokat három különálló osztályba oszthatjuk, hogy teljesítsük az elv célját.

Diák.java

js tömb

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

A fenti kódrészlet sérti az egységes felelősség elvét. Az elv céljának eléréséhez külön osztályt kell megvalósítanunk, amely csak egyetlen funkcionalitást lát el.

Diák.java

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

PrintStudentDetails.java

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

Százalék.java

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

Ezzel elértük az egységes felelősség elvének célját azzal, hogy a funkcionalitást három különálló osztályba osztottuk.

Nyitott-zárt elv

Az alkalmazás vagy modul entitásokat tartalmaz a metódusokat, függvényeket, változókat stb. A nyitott-zárt elv szerint az új követelményeknek megfelelően a modulnak nyitottnak kell lennie a bővítéshez, de zárva a módosításhoz. A kiterjesztés lehetővé teszi, hogy új funkciókat építsünk be a modulba. Értsük meg az elvet egy példán keresztül.

iphone hangulatjelek androidos telefonon

Tegyük fel, VehicleInfo egy osztály, és megvan a metódusa járműszám() amely visszaadja a jármű számát.

VehicleInfo.java

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

Ha egy másik teherautó nevű alosztályt szeretnénk hozzáadni, egyszerűen adjunk hozzá még egy if utasítást, amely sérti a nyitott-zárt elvet. Az egyetlen módja annak, hogy hozzáadjuk az alosztályt és elérjük az elvi célt azáltal, hogy felülírjuk a járműszám() módszerrel, ahogy az alábbiakban bemutattuk.

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

Hasonlóan további járműveket is hozzáadhatunk a járműosztályból egy másik alosztály létrehozásával. a megközelítés nem érintené a meglévő alkalmazást.

Liskov helyettesítési elv

A Liskov-helyettesítési elvet (LSP) vezette be Liskov Barbara . Az öröklésre úgy vonatkozik, hogy a a származtatott osztályoknak teljesen helyettesíthetőnek kell lenniük alaposztályaikkal . Más szóval, ha az A osztály a B osztály egyik altípusa, akkor képesnek kell lennünk B-t A-val helyettesíteni anélkül, hogy megszakítanánk a program viselkedését.

java színkódok

Kiterjeszti a nyitás-zárás elvet, és egy szuperosztály és altípusai viselkedésére is összpontosít. Úgy kell kialakítanunk az osztályokat, hogy megőrizzük az ingatlant, hacsak nincs nyomós okunk az ellenkezőjére. Értsük meg az elvet egy példán keresztül.

Diák.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); } } 

A fenti osztályok megsértették a Liskov helyettesítési elvet, mivel a StudentBMI osztálynak extra megkötései vannak, azaz a magasságnak és a súlynak azonosnak kell lennie. Ezért a Student osztály (alaposztály) nem helyettesíthető StudentBMI osztállyal (származott osztály).

Ezért a Student osztály StudentBMI osztályra cserélése váratlan viselkedést eredményezhet.

Interfész szegregációs elve

Az elv szerint a nagyobb interfészek kisebbekre válnak szét. Mivel a megvalósítási osztályok csak a szükséges metódusokat használják. Ne kényszerítsük az ügyfelet olyan módszerek használatára, amelyeket nem akar használni.

Az interfész szegregáció elvének célja hasonló az egyetlen felelősség elvéhez. Értsük meg az elvet egy példán keresztül.

sztringben összehasonlítani

Tegyük fel, hogy létrehoztunk egy interfészt, melynek neve Átalakítás három módszerrel intToDouble(), intToChar(), és charToString() .

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

A fenti interfésznek három módja van. Ha csak egy intToChar() metódust akarunk használni, akkor nincs más választásunk, hogy az egyetlen metódust implementáljuk. A probléma megoldása érdekében az elv lehetővé teszi, hogy az interfészt három különálló részre bontsuk.

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

Most már csak a szükséges módszert használhatjuk. Tegyük fel, hogy az egész számot duplává, a karaktert pedig stringgé akarjuk konvertálni, akkor csak a metódusokat fogjuk használni intToDouble() és charToString().

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

A függőségi inverzió elve

Az alapelv kimondja, hogy konkrét megvalósítások helyett absztrakciót (absztrakt osztályokat és interfészek) kell használnunk. A magas szintű modulok nem függhetnek az alacsony szintű moduloktól, de mindkettőnek az absztrakciótól kell függnie. Mert az absztrakció nem a részletektől függ, hanem a részlet az absztrakciótól. Leválasztja a szoftvert. Értsük meg az elvet egy példán keresztül.

 public class WindowsMachine { //functionality } 

Érdemes Windowson dolgozni, ha nincs billentyűzetünk és egerünk. A probléma megoldásához létrehozzuk az osztály konstruktorát, és hozzáadjuk a billentyűzet és a monitor példányait. A példányok hozzáadása után az osztály a következőképpen néz ki:

mysql egyedi kulcs

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

Most már a Windows gépen dolgozhatunk billentyűzet és egér segítségével. De még mindig szembesülünk a problémával. Mert az új kulcsszó használatával szorosan összekapcsoltuk a három osztályt. Nehéz tesztelni az osztály Windows gépét.

A kód laza csatolása érdekében a WindowsMachine-t leválasztjuk a billentyűzetről a Billentyűzet felület és a kulcsszó használatával.

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

A fenti kódban a függőségi injekciót használtuk a billentyűzet-függőség hozzáadásához a WindowsMachine osztályban. Ezért az osztályokat szétválasztottuk.

Miért használjunk SOLID elveket?

• Csökkenti a függőséget, így egy kódblokk megváltoztatható a többi kódblokk befolyásolása nélkül.
• Az alapelvek célja, hogy a tervezést könnyebbé, érthetővé tegyék.
• Az elvek használatával a rendszer karbantartható, tesztelhető, méretezhető és újrafelhasználható.
• Ez elkerüli a szoftver rossz tervezését.

Amikor legközelebb szoftvert tervez, tartsa szem előtt ezt az öt alapelvet. Ezen elvek alkalmazásával a kód sokkal áttekinthetőbb, tesztelhetőbb és elhasználhatóbb lesz.