Maapallon maailmassa (OOP), on olemassa monia suunnitteluohjeita, -malleja tai -periaatteita. Viisi näistä periaatteista on yleensä ryhmitelty yhteen ja ne tunnetaan lyhenteellä SOLID. Vaikka jokainen näistä viidestä periaatteesta kuvaa jotain erityistä, ne ovat päällekkäisiä myös siten, että toisen hyväksyminen merkitsee tai johtaa toisen omaksumiseen. Tässä artikkelissa ymmärrämme SOLID-periaatteet Javassa.
SOLID-periaatteiden historia Javalla
Robert C. Martin antoi viisi objektisuuntautunutta suunnitteluperiaatetta, ja siihen käytetään lyhennettä “S.O.L.I.D”. Kun käytät kaikkia S.O.L.I.D: n periaatteita yhdessä, sinun on helpompi kehittää helposti hallittavia ohjelmistoja. Muut S.O.L.I.D: n käytön ominaisuudet ovat:
- Se välttää koodin hajuja.
- Nopea taittokoodi.
- Osaa tehdä mukautuvaa tai ketterää ohjelmistokehitystä.
Kun käytät S.O.L.I.D-periaatetta koodauksessasi, aloitat koodin kirjoittamisen, joka on sekä tehokas että vaikuttava.
Mitä S.O.L.I.D tarkoittaa?
Solid edustaa jaavan viittä periaatetta, jotka ovat:
- S : Yhden vastuun periaate
- TAI : Avoin ja suljettu -periaate
- L : Liskovin korvausperiaate
- Minä : Liitännän erotteluperiaate
- D : Riippuvuuden kääntämisen periaate
Tässä blogissa käsitellään yksityiskohtaisesti kaikkia Java-järjestelmän viittä SOLID-periaatetta.
Yhden vastuun periaate Javalla
Mitä se sanoo?
kokki vs nukke vs mahdollista
Robert C. Martin kuvaa sitä, että yhdellä luokalla pitäisi olla vain yksi ja ainoa vastuu.
Yhden vastuun periaatteen mukaan luokkaa on muutettava vain yhden syyn vuoksi. Se tarkoittaa, että luokalla pitäisi olla yksi tehtävä. Tätä periaatetta kutsutaan usein subjektiiviseksi.
Periaate voidaan ymmärtää hyvin esimerkin avulla. Kuvittele, että on luokka, joka suorittaa seuraavat toiminnot.
Yhdistetty tietokantaan
Lue joitain tietoja tietokantataulukoista
Kirjoita lopuksi tiedosto.
Oletko kuvitellut tilanteen? Tässä luokassa on useita syitä muutokseen, ja harvat niistä ovat tiedostotiedoston muokkaamista, uuden tietokannan hyväksymistä. Kun puhumme yhden periaatteen vastuusta, sanoisimme, että luokassa on liian monia syitä muuttua, joten se ei sovi oikein yhden vastuun periaatteeseen.
Esimerkiksi Automobile-luokka voi käynnistää tai pysäyttää itsensä, mutta sen pesu kuuluu CarWash-luokkaan. Toisessa esimerkissä Book-luokassa on ominaisuuksia, jotka tallentavat oman nimen ja tekstin. Kirjan tulostamisen on kuitenkin kuuluttava Kirjatulostin-luokkaan. Kirjatulostin-luokka saattaa tulostaa konsolille tai muulle tallennusvälineelle, mutta tällaiset riippuvuudet poistetaan Kirjaluokasta
Miksi tätä periaatetta vaaditaan?
Kun yhden vastuun periaatetta noudatetaan, testaus on helpompaa. Yhdellä vastuulla luokassa on vähemmän testitapauksia. Vähemmän toiminnallisuutta tarkoittaa myös vähemmän riippuvuuksia muista luokista. Se johtaa parempaan koodijärjestelyyn, koska pienempiä ja tarkoituksenmukaisempia luokkia on helpompi etsiä.
Esimerkki tämän periaatteen selventämiseksi:
Oletetaan, että sinua pyydetään ottamaan käyttöön UserSetting-palvelu, jossa käyttäjä voi muuttaa asetuksia, mutta ennen sitä käyttäjä on todennettava. Yksi tapa toteuttaa tämä olisi:
public class UserSettingService {public void changeEmail (User user) {if (checkAccess (user)) {// Myönnä muutosvaihtoehto}} public boolean checkAccess (User user) {// Tarkista, onko käyttäjä kelvollinen. }}Kaikki näyttää hyvältä, kunnes haluat käyttää checkAccess-koodia uudelleen jossakin muussa paikassa TAI haluat muuttaa muutoksia checkAccess-toiminnon tapaan. Kaikissa kahdessa tapauksessa päädyt vaihtamaan samaa luokkaa, ja ensimmäisessä tapauksessa sinun on käytettävä UserSettingServicea myös pääsyn tarkistamiseksi.
Yksi tapa korjata tämä on hajottaa UserSettingService osaksi UserSettingService ja SecurityService. Ja siirrä checkAccess-koodi SecurityServiceen.
public class UserSettingService {public void changeEmail (User user) {if (SecurityService.checkAccess (user)) {// Grant option to change}}} public class SecurityService {public static boolean checkAccess (User user) {// tarkista käyttöoikeus. }}Avaa suljettu periaate Java-sovelluksessa
Robert C. Martin kuvailee sitä, että ohjelmistokomponenttien pitäisi olla auki laajennusta varten, mutta suljettu muokkausta varten.
Tarkemmin sanottuna tämän periaatteen mukaan luokka on kirjoitettava siten, että se suorittaa työnsä moitteettomasti ilman, että oletetaan, että ihmiset tulevaisuudessa yksinkertaisesti tulevat ja muuttavat sitä. Siksi luokan tulisi pysyä suljettuna muokkaamista varten, mutta sillä tulisi olla mahdollisuus laajentaa. Luokan laajentamistapoja ovat:
Periytyminen luokasta
Korvaa luokan vaaditut käyttäytymismuodot
Luokan tiettyjen käyttäytymismuotojen laajentaminen
Erinomainen esimerkki avoimesta suljetusta -periaatteesta voidaan ymmärtää selainten avulla. Muistatko asentaneen laajennukset Chrome-selaimeesi?
Kromiselaimen perustoiminto on surffata eri sivustoissa. Haluatko tarkistaa kieliopin kirjoittaessasi sähköpostia Chrome-selaimella? Jos kyllä, voit yksinkertaisesti käyttää Grammarly-laajennusta, se antaa sinulle kieliopin tarkistuksen sisällölle.
Tämä mekanismi, johon lisäät asioita selaimen toiminnallisuuden lisäämiseksi, on laajennus. Siksi selain on täydellinen esimerkki toiminnallisuudesta, joka on avoin laajennukselle, mutta on suljettu muokkaamista varten. Yksinkertaisesti sanottuna voit parantaa toiminnallisuutta lisäämällä / asentamalla laajennuksia selaimeesi, mutta et voi rakentaa mitään uutta.
Miksi tätä periaatetta vaaditaan?
OCP on tärkeä, koska luokat voivat tulla luoksemme ulkopuolisten kirjastojen kautta. Meidän pitäisi pystyä laajentamaan näitä luokkia huolimatta siitä, tukevatko nämä perusluokat laajennuksiamme. Perintö voi kuitenkin johtaa alaluokkiin, jotka riippuvat perusluokan toteutuksesta. Tämän välttämiseksi on suositeltavaa käyttää rajapintoja. Tämä ylimääräinen imeytyminen johtaa löysään kytkentään.
Sanotaan, että meidän on laskettava eri muotoiset alueet. Aloitetaan luomalla luokka ensimmäistä muotoamme suorakulmiota vartenjolla on 2 määritteen pituutta& leveys.
julkinen luokka Suorakulmio {julkinen kaksinkertainen pituus julkinen kaksinkertainen leveys}Seuraavaksi luomme luokan tämän suorakulmion pinta-alan laskemiseksijolla on menetelmä calcRectangleAreajoka vie Suorakulmiontuloparametrina ja laskee sen pinta-alan.
julkinen luokka AreaCalculator {julkinen kaksinkertainen calcRectangleArea (suorakulmion suorakulmio) {return rectangle.length * rectangle.width}}Toistaiseksi niin hyvä. Oletetaan nyt, että saamme toisen muodon ympyrän. Joten luomme nopeasti uuden luokan ympyränyhdellä attribuuttisäteellä.
julkisen luokan ympyrä {julkinen kaksinkertainen säde}Sitten muokkaamme Areacalculatorialuokka lisätä ympyrälaskennat uudella menetelmällä calcCircleaArea ()
julkinen luokka AreaCalculator {julkinen kaksinkertainen laskentakaava (suorakulmion suorakulmio) {paluu suorakulmion.pituus * suorakulmion.leveys} julkinen kaksinkertainen laskettuCircleArea (ympyräympyrä) {paluu (22/7) * ympyrä.säde * ympyrä.säde}}Huomaa kuitenkin, että ratkaisumme suunnittelussa oli virheitä.
Sanotaan, että meillä on uusi muotoinen viisikulmio. Siinä tapauksessa päätämme jälleen muuttaa AreaCalculator-luokkaa. Muodotyyppien kasvaessa tämä muuttuu epämuodollisemmaksi, kun AreaCalculator muuttuu jatkuvasti, ja kaikkien tämän luokan kuluttajien on päivitettävä AreaCalculatoria sisältäviä kirjastojaan. Tämän seurauksena AreaCalculator-luokkaa ei perusteta (viimeistelemällä) vakuudella, koska joka kerta, kun uusi muoto tulee, sitä muokataan. Joten tämä malli ei ole suljettu muokkausta varten.
AreaCalculatorin on lisättävä laskentalogiikkaansa uudemmissa menetelmissä. Emme todellakaan laajenna muotojen laajuutta, vaan teemme yksinkertaisesti kappaleen aterian (bit-by-bit) ratkaisun jokaiselle lisätylle muodolle.
Edellä olevan suunnittelun muokkaaminen avoimen / suljetun periaatteen mukaiseksi:
Katsotaan nyt tyylikkäämpi muotoilu, joka ratkaisee yllä olevan suunnittelun puutteet noudattamalla avointa / suljettua periaatetta. Teemme ensinnäkin suunnittelusta laajennettavan. Tätä varten meidän on ensin määriteltävä perustyyppinen muoto ja oltava Circle & Rectangle -muodon rajapinta.
julkinen käyttöliittymä Muoto {julkinen kaksinkertainen laskenta-alue ()} julkinen luokka Suorakulmion muotoiset muodot {kaksinkertainen pituus kaksinkertainen leveys julkinen kaksinkertainen laskenta-alue () {paluupituus * leveys}} julkinen luokka Ympyrä toteuttaa muodon {julkinen kaksinkertainen säde julkinen kaksinkertainen laskenta-alue () {paluu (22 / 7) * säde * säde}}Peruskäyttöliittymän muoto on. Kaikki muodot toteuttavat nyt peruskäyttöliittymän muodon. Muotoliitännällä on abstrakti menetelmä calcArea (). Sekä ympyrä että suorakulmio tarjoavat oman ohitetun calcArea () -menetelmän toteutuksen omia määritteitään käyttäen.
Olemme tuoneet sisään jonkin verran laajennettavuutta, koska muodot ovat nyt esimerkki Shape-rajapinnoista. Tämä antaa meille mahdollisuuden käyttää muotoa yksittäisten luokkien sijaan
Viimeinen edellä mainittu kohta mainitsi näiden muotojen kuluttajan. Meidän tapauksessamme kuluttaja on AreaCalculator-luokka, joka näyttäisi nyt tältä.
public class AreaCalculator {julkinen kaksinkertainen calcShapeArea (muodon muoto) {return shape.calculateArea ()}}Tämä AreaCalculatorluokka poistaa nyt täysin edellä mainitut suunnitteluvirheemme ja antaa puhtaan ratkaisun, joka noudattaa avointa suljettua periaatetta. Siirrytään eteenpäin muiden SOLID-periaatteiden kanssa Javassa
Liskovin korvausperiaate Javassa
Robert C. Martin kuvaa sitä, että johdettujen tyyppien on oltava täysin korvattavissa perustyypeillään.
Liskovin korvausperiaate olettaa, että q (x) on ominaisuus, joka voidaan todistaa tyypin T piiriin kuuluvien x: n entiteettien suhteen. Tämän periaatteen mukaan q (y): n pitäisi nyt olla todistettavissa tyypille S kuuluville kohteille y, ja S on itse asiassa T: n alatyyppi. Oletko nyt hämmentynyt etkä tiedä mitä Liskovin korvausperiaate todella tarkoittaa? Sen määritelmä voi olla hieman monimutkainen, mutta itse asiassa se on melko helppoa. Ainoa asia on, että jokaisen alaluokan tai johdetun luokan tulisi olla korvattavissa vanhemman tai perusluokan kanssa.
Voit sanoa, että se on ainutlaatuinen olio-periaate. Periaatetta voidaan edelleen yksinkertaistaa tietyntyyppisen lapsityypin lapsityypillä tekemättä mitään komplikaatioita tai räjäyttämättä asioita, sillä pitäisi olla mahdollisuus puolustaa vanhempaa. Tämä periaate liittyy läheisesti Liskovin korvausperiaatteeseen.
Miksi tätä periaatetta vaaditaan?
Näin vältetään perinnön väärinkäyttö. Se auttaa meitä noudattamaan 'on-a' -suhdetta. Voimme myös sanoa, että alaluokkien on täytettävä perusluokan määrittämä sopimus. Tässä mielessä se liittyySuunnittelu sopimuksen mukaanjonka Bertrand Meyer kuvasi ensin. Esimerkiksi on houkuttelevaa sanoa, että ympyrä on eräänlainen ellipsi, mutta ympyröillä ei ole kahta polttopistettä tai isompaa / pienempää akselia.
LSP selitetään yleisesti käyttämällä neliön ja suorakulmion esimerkkiä. jos oletetaan ISA-suhde Neliön ja Suorakulmion välillä. Siksi kutsumme 'neliö on suorakulmio'. Alla oleva koodi edustaa suhdetta.
public class Suorakulmio {private int length private int leveys public int getLength () {return length} public void setLength (int length) {this.length = length} public int getBreadth () {return width} public void setBreadth (int leveys) { tämä.leveys = leveys} public int getArea () {return this.length * this.breadth}}Alla on neliön koodi. Huomaa, että Neliö laajentaa suorakulmiota.
julkisen luokan neliö ulottuu suorakulmio {public void setBreadth (int leveys) {super.setBreadth (leveys) super.setLength (leveys)} public void setLength (int pituus) {super.setLength (pituus) super.setBreadth (pituus)}}Tässä tapauksessa yritämme muodostaa ISA-suhteen Neliön ja Suorakulmion välille siten, että kutsuminen 'Neliö on suorakulmio' alla olevassa koodissa alkaa käyttäytyä odottamattomasti, jos Neliön esiintymä välitetään. Vahvistusvirhe heitetään, jos tarkistetaan alue ja alue tarkistetaan, onko alue leveys, vaikka ohjelma päättyy, kun väite virheestä heitetään alueen tarkistuksen epäonnistumisen vuoksi.
julkinen luokka LSPDemo {public void calcArea (suorakulmio r) {r.setBreadth (2) r.setLength (3) väittävät r.getArea () == 6: printError ('alue', r) väittävät r.getLength () == 3: printError ('length', r) väittää r.getBreadth () == 2: printError ('width', r)} private String printError (String errorIdentifer, Rectangle r) {return 'Odottamaton arvo' + errorIdentifer + ' esimerkiksi '+ r.getClass (). getName ()} public static void main (String [] args) {LSPDemo lsp = new LSPDemo () // Suorakulmion esiintymä välitetään lsp.calculateArea (new Rectangle ()) // Neliön esiintymä välitetään lsp.calculateArea (new Square ())}} Luokka osoittaa Liskov Substitution Principlen (LSP) Periaatteen mukaisesti toimintojen, jotka käyttävät viitteitä perusluokkiin, on kyettävä käyttämään johdetun luokan objekteja tuntematta sitä.
Täten alla olevassa esimerkissä funktion calcArea, joka käyttää suorakulmion viitteitä, pitäisi pystyä käyttämään johdetun luokan objekteja, kuten Neliö, ja täyttämään suorakulmion määritelmän asettamat vaatimukset. On huomattava, että suorakulmion määritelmän mukaisesti seuraavien on aina pidettävä paikkansa seuraavien tietojen perusteella:
- Pituuden on aina oltava sama kuin menetelmä, setLength
- Leveyden on aina oltava yhtä suuri kuin menetelmän setBreadth syötteen leveys
- Pinta-alan on aina oltava yhtä suuri kuin pituuden ja leveyden tulo
Yritämme luoda ISA-suhde Neliön ja Suorakulmion välille siten, että kutsumme 'Neliö on suorakulmio'. Yllä oleva koodi alkaa käyttäytyä odottamattomasti, jos Neliön esiintymä hyväksytään. Vahvistusvirhe heitetään alueen ja tarkistuksen yhteydessä vaikka ohjelma päättyy, kun väite virheestä heitetään alueen tarkistuksen epäonnistumisen vuoksi.
Square-luokka ei vaadi menetelmiä, kuten setBreadth tai setLength. LSPDemo-luokan on tiedettävä suorakulmion johdettujen luokkien (kuten neliön) yksityiskohdat koodaamaan asianmukaisesti heittovirheiden välttämiseksi. Nykyisen koodin muutos rikkoo avoimen ja suljetun periaatteen.
Liitännän erottelun periaate
Robert C. Martin kuvailee sitä, että asiakkaita ei pitäisi pakottaa toteuttamaan tarpeettomia menetelmiä, joita he eivät käytä.
MukaanLiitännän erotteluperiaateasiakas, riippumatta siitä, mitä ei koskaan pidä pakottaa toteuttamaan käyttöliittymää, jota se ei käytä, tai asiakasta ei pitäisi koskaan velvoittaa riippumaan mistään menetelmästä, jota he eivät käytä. Joten periaatteessa käyttöliittymän erotteluperiaatteet, kuten haluat käyttöliittymät, jotka ovat pieniä, mutta asiakaskohtaisia monoliittisen ja isomman käyttöliittymän sijaan. Lyhyesti sanottuna sinun olisi huono pakottaa asiakas pakottamaan asiakas riippumaan tietystä asiasta, jota he eivät tarvitse.
Esimerkiksi yksi lokirajapinta lokien kirjoittamiseen ja lukemiseen on hyödyllinen tietokannalle, mutta ei konsolille. Lokien lukemisella ei ole mitään merkitystä konsolilokiin. Siirtyminen tämän SOLID-periaatteiden Java-artikkeliin.
Miksi tätä periaatetta vaaditaan?
Sanotaan, että ravintolassa on käyttöliittymä, joka sisältää tapoja hyväksyä tilauksia verkkoasiakkailta, puhelin- tai puhelinasiakkailta ja sisäänkäynnin asiakkailta. Se sisältää myös tapoja käsitellä verkkomaksuja (online-asiakkaille) ja henkilökohtaisia maksuja (kävijöille ja puhelinasiakkaille, kun heidän tilauksensa toimitetaan kotona).
Luodaan nyt Java-käyttöliittymä ravintolalle ja nimetään se nimellä RestaurantInterface.java.
julkinen käyttöliittymä RestaurantInterface {public void acceptOnlineOrder () public void takeTelephoneOrder () public void payOnline () public void walkInCustomerOrder () public void payInPerson ()}RestaurantInterface-sovelluksessa on määritelty 5 menetelmää, jotka ovat verkkotilausten hyväksyminen, puhelintilausten ottaminen, tilausten vastaanottaminen sisäänostetulta asiakkaalta, verkkomaksun hyväksyminen ja maksun hyväksyminen henkilökohtaisesti.
Aloitetaan toteuttamalla RestaurantInterface online-asiakkaille nimellä OnlineClientImpl.java
public class OnlineClientImpl toteuttaa RestaurantInterface {public void acceptOnlineOrder () {// logiikka online-tilauksen tekemiseen} public void takeTelephoneOrder () {// Ei sovellettavissa verkkotilauksiin heittää uusi UnsupportedOperationException ()} public void payOnline () {// maksamisen logiikka online} public void walkInCustomerOrder () {// Ei sovellettavissa verkkotilauksiin, heitä uusi UnsupportedOperationException ()} public void payInPerson () {// Ei sovellettavissa verkkotilauksiin, heitä uusi UnsupportedOperationException ()}}Koska yllä oleva koodi (OnlineClientImpl.java) on tarkoitettu verkkotilauksille, heitä UnsupportedOperationException.
Online-, puhelin- ja sisäänkäynnin asiakkaat käyttävät kullekin erityistä RestaurantInterface-toteutusta.
Telephonic-asiakkaan ja Walk-in-asiakkaan toteutusluokilla on tukemattomia menetelmiä.
Koska 5 menetelmää ovat osa RestaurantInterface-liitäntää, toteutusluokkien on toteutettava kaikki 5.
Menetelmät, jotka kukin toteutusluokista heittää UnsupportedOperationException. Kuten voit selvästi nähdä - kaikkien menetelmien toteuttaminen on tehotonta.
Kaikki muutokset RestaurantInterface-menetelmien menetelmissä levitetään kaikkiin toteutusluokkiin. Koodin ylläpito alkaa sitten tulla todella hankalaksi ja muutosten regressiovaikutukset kasvavat jatkuvasti.
kuinka käyttää iteraattoria
RestaurantInterface.java rikkoo yhden vastuun periaatetta, koska maksujen logiikka ja tilausten logiikka on ryhmitelty yhteen käyttöliittymään.
Yllä mainittujen ongelmien ratkaisemiseksi käytämme Interface Segregation Principle -ohjelmaa uudistamaan yllä olevaa rakennetta.
Erota maksu- ja tilaustoiminnot kahteen erilliseen vähäiseen käyttöliittymään, PaymentInterface.java ja OrderInterface.java.
Jokainen asiakas käyttää yhtä toteutustapaa, molemmat PaymentInterface- ja OrderInterface-sovelluksista. Esimerkiksi - OnlineClient.java käyttää OnlinePaymentImpl ja OnlineOrderImpl ja niin edelleen.
Yhden vastuun periaate on nyt liitetty maksuliittymänä (PaymentInterface.java) ja tilausliittymänä (OrderInterface).
Minkä tahansa tilaus- tai maksurajapinnan muutos ei vaikuta toiseen. Ne ovat nyt itsenäisiä, eikä sinun tarvitse tehdä mitään nuken toteutusta tai heittää UnsupportedOperationException-ohjelmaa, koska jokaisella käyttöliittymällä on vain menetelmät, joita se aina käyttää.
Internet-palveluntarjoajan soveltamisen jälkeen
Riippuvuuden kääntämisen periaate
Robert C. Martin kuvailee sitä, koska se riippuu abstraktioista, ei konkretioista, sen mukaan korkean tason moduuli ei saa koskaan luottaa mihinkään matalan tason moduuliin. esimerkiksi
Menet paikalliseen kauppaan ostamaan jotain ja päätät maksaa siitä maksukortillasi. Joten kun annat korttisi virkailijalle maksun suorittamiseksi, virkailija ei vaivaudu tarkistamaan, minkälaisen kortin olet antanut.
Vaikka olisit antanut Visa-kortin, hän ei laita Visa-konetta kortin pyyhkäisemiseksi. Luottokortti- tai maksukorttisi tyyppi, jolla maksat, ei ole väliä, he vain pyyhkäisevät sen. Joten tässä esimerkissä näet, että sekä sinä että virkailija olet riippuvainen luottokortin otosta etkä ole huolissasi kortin erityispiirteistä. Tämä on riippuvuuden inversioperiaate.
Miksi tätä periaatetta vaaditaan?
Sen avulla ohjelmoija voi poistaa kovakoodatut riippuvuudet, jotta sovelluksesta tulee löyhästi kytketty ja laajennettavissa.
julkinen luokka Opiskelija {yksityisen osoitteen osoite julkinen opiskelija () {osoite = uusi osoite ()}}Edellä olevassa esimerkissä Opiskelija-luokka vaatii Osoite-objektin ja se on vastuussa Osoite-objektin alustamisesta ja käytöstä. Jos osoiteluokkaa muutetaan tulevaisuudessa, meidän on tehtävä muutoksia myös opiskelijaluokassa. Tämä tekee tiukan kytkennän opiskelija- ja osoitekohteiden välillä. Voimme ratkaista tämän ongelman riippuvuuden inversiosuunnittelumallin avulla. ts. osoiteobjekti toteutetaan itsenäisesti ja se toimitetaan Opiskelijalle, kun Opiskelija havainnollistetaan käyttämällä konstruktoripohjaista tai asettajapohjaista riippuvuusinversiota.
Tämän myötä olemme päässeet päätökseen tämän SOLID-periaatteiden kanssa Javassa.
Katso Edureka, luotettava verkko-oppimisyritys, jolla on yli 250 000 tyytyväisen oppijan verkosto, joka levisi ympäri maailmaa. Edurekan Java J2EE- ja SOA-koulutus- ja sertifiointikurssit on suunniteltu opiskelijoille ja ammattilaisille, jotka haluavat olla Java-kehittäjiä. Kurssi on suunniteltu antamaan sinulle etumatka Java-ohjelmointiin ja kouluttamaan sekä ydin- että edistyneitä Java-konsepteja sekä erilaisia Java-kehyksiä, kuten Hibernate & Spring.
Onko sinulla kysymys meille? Mainitse se tämän SOLID Principles in Java -blogin kommenttiosassa, niin otamme sinuun yhteyttä mahdollisimman pian.