Javalla, KIINTEÄT periaatteet ovat oliolähtöinen lähestymistapa, jota sovelletaan ohjelmistorakenteen suunnitteluun. Sen käsitteellistää Robert C. Martin (tunnetaan myös nimellä Bob-setä). Nämä viisi periaatetta ovat muuttaneet olio-ohjelmoinnin maailmaa ja muuttaneet myös ohjelmistojen kirjoitustapaa. Se myös varmistaa, että ohjelmisto on modulaarinen, helposti ymmärrettävä, virheenkorjaus ja uudelleenkäytettävä. Tässä osiossa keskustelemme SOLID-periaatteet Javassa oikealla esimerkillä .
Sanan SOLID lyhenne sanoille:
- Yhden vastuun periaate (SRP)
- Open-Closed Principe (OCP)
- Liskovin korvausperiaate (LSP)
- Interface Segregation Principle (ISP)
- Riippuvuuden inversioperiaate (DIP)
Selitetään periaatteet yksitellen yksityiskohtaisesti.
java tietorakenteet
Yhden vastuun periaate
Yhtenäisen vastuun periaate sanoo sen jokaisen Java-luokan on suoritettava yksi toiminto . Useiden toimintojen toteuttaminen yhdessä luokassa sekoittaa koodin ja jos muutoksia tarvitaan, se voi vaikuttaa koko luokkaan. Se tarkottaa koodia ja koodia voidaan helposti ylläpitää. Ymmärretään yhden vastuun periaate esimerkin kautta.
Olettaa, Opiskelija on luokka, jossa on kolme menetelmää printDetails(), laske prosenttiosuus(), ja addStudent(). Siten Opiskelijaluokalla on kolme tehtävää tulostaa opiskelijoiden tiedot, laskea prosenttiosuudet ja tietokanta. Yhden vastuun periaatetta käyttämällä voimme jakaa nämä toiminnallisuudet kolmeen erilliseen luokkaan periaatteen tavoitteen saavuttamiseksi.
Opiskelija.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 } } Yllä oleva koodinpätkä rikkoo yhden vastuun periaatetta. Periaatteen tavoitteen saavuttamiseksi meidän tulisi toteuttaa erillinen luokka, joka suorittaa vain yhden toiminnon.
Opiskelija.java
public class Student { public void addStudent(); { //functionality of the method } } TulostaStudentDetails.java
public class PrintStudentDetails { public void printDetails(); { //functionality of the method } } Prosentti.java
public class Percentage { public void calculatePercentage(); { //functionality of the method } } Olemme siis saavuttaneet yhden vastuun periaatteen tavoitteen jakamalla toiminnallisuuden kolmeen eri luokkaan.
Avoin-suljettu periaate
Sovellus tai moduuli kokoaa menetelmät, funktiot, muuttujat jne. Avoin-kiinni -periaatteen mukaan uusien vaatimusten mukaan moduulin tulee olla auki laajennusta varten, mutta suljettu muutosta varten. Laajennuksen avulla voimme ottaa käyttöön uusia toimintoja moduuliin. Ymmärretään periaate esimerkin kautta.
Olettaa, VehicleInfo on luokka ja sillä on menetelmä ajoneuvonnumero() joka palauttaa ajoneuvon numeron.
VehicleInfo.java
public class VehicleInfo { public double vehicleNumber(Vehicle vcl) { if (vcl instanceof Car) { return vcl.getNumber(); if (vcl instanceof Bike) { return vcl.getNumber(); } } Jos haluamme lisätä toisen alaluokan nimeltä Truck, lisäämme yksinkertaisesti yhden if-lausekkeen, joka rikkoo auki-kiinni -periaatetta. Ainoa tapa lisätä alaluokka ja saavuttaa periaatetavoite ohittamalla ajoneuvonnumero() menetelmällä, kuten olemme osoittaneet alla.
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(); } Vastaavasti voimme lisätä ajoneuvoja tekemällä toisen alaluokan ajoneuvoluokasta. lähestymistapa ei vaikuttaisi olemassa olevaan sovellukseen.
Liskovin substituutioperiaate
Liskovin substituutioperiaatteen (LSP) esitteli Barbara Liskov . Sitä sovelletaan perintöön siten, että johdettujen luokkien on oltava täysin korvattavissa perusluokkiillaan . Toisin sanoen, jos luokka A on luokan B alatyyppi, meidän pitäisi pystyä korvaamaan B A:lla keskeyttämättä ohjelman toimintaa.
Se laajentaa open-close -periaatetta ja keskittyy myös superluokan ja sen alatyyppien käyttäytymiseen. Meidän tulee suunnitella luokat säilyttämään omaisuutta, ellei meillä ole painavaa syytä toimia toisin. Ymmärretään periaate esimerkin kautta.
Opiskelija.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); } } Yllä olevat luokat rikkoivat Liskov-korvausperiaatetta, koska StudentBMI-luokassa on ylimääräisiä rajoituksia eli pituuden ja painon on oltava samat. Siksi Student-luokkaa (perusluokka) ei voi korvata StudentBMI-luokalla (johdettu luokka).
Siksi luokan Student korvaaminen StudentBMI-luokalla voi johtaa odottamattomaan käyttäytymiseen.
Käyttöliittymän erotteluperiaate
Periaatteen mukaan suuremmat rajapinnat jaetaan pienempiin. Koska toteutusluokat käyttävät vain vaadittuja menetelmiä. Emme saa pakottaa asiakasta käyttämään menetelmiä, joita hän ei halua käyttää.
Rajapintojen erotteluperiaatteen tavoite on samanlainen kuin yhden vastuun periaate. Ymmärretään periaate esimerkin kautta.
Oletetaan, että olemme luoneet käyttöliittymän nimeltä Muuntaminen jolla on kolme menetelmää intToDouble(), intToChar(), ja charToString() .
jos muuten silmukka javassa
public interface Conversion { public void intToDouble(); public void intToChar(); public void charToString(); } Yllä olevassa käyttöliittymässä on kolme tapaa. Jos haluamme käyttää vain menetelmää intToChar(), meillä ei ole vaihtoehtoa toteuttaa yhtä menetelmää. Ongelman ratkaisemiseksi periaate antaa meille mahdollisuuden jakaa käyttöliittymä kolmeen erilliseen osaan.
public interface ConvertIntToDouble { public void intToDouble(); } public interface ConvertIntToChar { public void intToChar(); } public interface ConvertCharToString { public void charToString(); } Nyt voimme käyttää vain vaadittua menetelmää. Oletetaan, että haluamme muuntaa kokonaisluvun kaksoisluvuksi ja merkin merkkijonoksi, niin käytämme vain menetelmiä intToDouble() ja charToString().
public class DataTypeConversion implements ConvertIntToDouble, ConvertCharToString { public void intToDouble() { //conversion logic } public void charToString() { //conversion logic } } Riippuvuuden inversioperiaate
Periaatteen mukaan meidän on käytettävä abstraktiota (abstrakteja luokkia ja rajapintoja) konkreettisten toteutusten sijaan. Korkean tason moduulien ei pitäisi olla riippuvaisia matalan tason moduulista, mutta molempien tulisi riippua abstraktiosta. Koska abstraktio ei riipu yksityiskohdista, vaan yksityiskohdat riippuvat abstraktiosta. Se irrottaa ohjelmiston. Ymmärretään periaate esimerkin kautta.
public class WindowsMachine { //functionality } Jos meillä ei ole näppäimistöä ja hiirtä, kannattaa toimia Windowsissa. Tämän ongelman ratkaisemiseksi luomme luokan rakentajan ja lisäämme näppäimistön ja näytön esiintymät. Ilmentymien lisäämisen jälkeen luokka näyttää tältä:
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 } } Nyt voimme työskennellä Windows-koneella näppäimistön ja hiiren avulla. Mutta kohtaamme edelleen ongelman. Koska olemme yhdistäneet kolme luokkaa tiiviisti yhteen käyttämällä uutta avainsanaa. On vaikea testata luokan Windows-konetta.
Jotta koodi olisi löyhästi kytketty, irrotamme WindowsMachinen näppäimistöstä käyttämällä näppäimistöliittymää ja tätä avainsanaa.
Näppäimistö.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; } } Yllä olevassa koodissa olemme käyttäneet riippuvuusinjektiota lisätäksemme näppäimistöriippuvuuden WindowsMachine-luokkaan. Siksi olemme erottaneet luokat.
Miksi meidän pitäisi käyttää SOLID-periaatteita?
- Se vähentää riippuvuuksia niin, että koodilohkoa voidaan muuttaa vaikuttamatta muihin koodilohkoihin.
- Periaatteet on tarkoitettu tekemään suunnittelusta helpompaa, ymmärrettävää.
- Periaatteita käyttämällä järjestelmä on ylläpidettävä, testattava, skaalautuva ja uudelleenkäytettävä.
- Se välttää ohjelmiston huonon suunnittelun.
Kun seuraavan kerran suunnittelet ohjelmistoja, pidä nämä viisi periaatetta mielessä. Näitä periaatteita soveltamalla koodi on paljon selkeämpi, testattavampi ja kuluttavampi.