Viskas, ką reikia žinoti apie tvirtus „Java“ principus

Pasaulyje (OOP), yra daug dizaino gairių, modelių ar principų. Penki iš šių principų paprastai yra sugrupuoti ir yra žinomi santrumpa SOLID. Nors kiekvienas iš šių penkių principų apibūdina kažką konkretaus, jie taip pat sutampa, kad vieno iš jų priėmimas reiškia arba paskatina priimti kitą. Šiame straipsnyje mes suprasime SOLID principus „Java“.

• SOLID principų istorija Java
• Ką reiškia S.O.L.I.D?

SOLID principų istorija Java

Robertas C. Martinas pateikė penkis objektinio projektavimo principus, o jam naudojamas trumpinys „S.O.L.I.D“. Kai visus S.O.L.I.D principus naudosite kartu, jums taps lengviau kurti lengvai valdomą programinę įrangą. Kitos S.O.L.I.D naudojimo savybės yra šios:

• Tai vengia kodo kvapų.
• Greitai refrakto kodas.
• Geba kurti adaptyvią ar judrią programinę įrangą.

Kai koduodami naudojate S.O.L.I.D principą, pradedate rašyti efektyvų ir efektyvų kodą.

Ką reiškia S.O.L.I.D?

„Solid“ reiškia penkis „Java“ principus:

• S : Vienos atsakomybės principas
• ARBA : Atviro ir uždaro principas
• L : Liskovo pakeitimo principas
• Aš : Sąsajos atskyrimo principas
• D : Priklausomybės inversijos principas

Šiame tinklaraštyje išsamiai aptarsime visus penkis „SOLID“ „Java“ principus.

Vienos atsakomybės principas „Java“

Ką tai sako?

Robertas C. Martinas apibūdina, kad vienai klasei tenka tik viena ir vienintelė atsakomybė.

Pagal vienos atsakomybės principą turėtų būti tik viena priežastis, dėl kurios klasė turi būti pakeista. Tai reiškia, kad klasė turėtų atlikti vieną užduotį. Šis principas dažnai vadinamas subjektyviu.

Principą galima gerai suprasti pavyzdžiu. Įsivaizduokite, kad yra klasė, atliekanti šias operacijas.

• Prisijungta prie duomenų bazės

  nustatant Java užtemimą

• Perskaitykite kai kuriuos duomenis iš duomenų bazės lentelių

• Galiausiai užrašykite jį į failą.

Ar įsivaizdavote scenarijų? Čia klasei yra kelios priežastys, dėl kurių reikia pakeisti, ir nedaugelis iš jų yra failo išvesties modifikavimas, naujos duomenų bazės priėmimas. Kai mes kalbame apie vienintelę principinę atsakomybę, sakytume, yra per daug priežasčių, kodėl klasė turi keistis, todėl ji netinkama vienos atsakomybės principui.

Pavyzdžiui, automobilių klasė gali pradėti arba sustabdyti save, tačiau jos plovimo užduotis priklauso „CarWash“ klasei. Kitame pavyzdyje „Book“ klasė turi savybių savo vardui ir tekstui saugoti. Bet knygos spausdinimo užduotis turi priklausyti Knygų spausdintuvų klasei. Knygų spausdintuvų klasė gali būti spausdinama konsolėje ar kitoje laikmenoje, tačiau tokios priklausomybės pašalinamos iš knygų klasės

Kodėl reikalingas šis principas?

Kai laikomasi vienos atsakomybės principo, testuoti yra lengviau. Prisiimant vieną atsakomybę, klasėje bus mažiau bandomųjų atvejų. Mažesnis funkcionalumas reiškia ir mažiau priklausomybių nuo kitų klasių. Tai leidžia geriau tvarkyti kodus, nes mažesnėse ir tikslingose ​​klasėse lengviau ieškoti.

Šio principo paaiškinimo pavyzdys:

Tarkime, jūsų paprašoma įdiegti „UserSetting“ paslaugą, kurioje vartotojas gali pakeisti nustatymus, tačiau prieš tai jis turi būti patvirtintas. Vienas iš būdų tai įgyvendinti būtų:

public class „UserSettingService“ {public void changeEmail (User user) {if (checkAccess (user)) {// Suteikti parinktį pakeisti}} public Boolean checkAccess (User user) {// Patikrinkite, ar vartotojas galioja. }}

Viskas atrodo gerai, kol nenorite pakartotinai naudoti „checkAccess“ kodo kitoje vietoje ARBA norite pakeisti „checkAccess“ atlikimo būdą. Visais 2 atvejais galų gale pakeistumėte tą pačią klasę ir pirmuoju atveju turėtumėte naudoti „UserSettingService“, kad patikrintumėte ir prieigą.
Vienas iš būdų tai ištaisyti yra „UserSettingService“ suskaidymas į „UserSettingService“ ir „SecurityService“. Ir perkelkite „checkAccess“ kodą į „SecurityService“.

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) {// patikrinkite prieigą. }}

„Java“ atidarykite uždarą principą

Robertas C. Martinas apibūdina, kad programinės įrangos komponentai turėtų būti atviri išplėtimui, tačiau uždaryti modifikavimui.

Tiksliau sakant, pagal šį principą klasė turėtų būti parašyta taip, kad ji savo darbą atliktų nepriekaištingai, nedarydama prielaidos, kad ateityje žmonės tiesiog ateis ir ją pakeis. Taigi klasė turėtų likti uždaryta dėl modifikavimo, tačiau ji turėtų turėti galimybę pratęsti. Klasės išplėtimo būdai:

• Paveldimas iš klasės

• Reikalingo klasės elgesio perrašymas

• Tam tikro klasės elgesio išplėtimas

Puikus atviro-uždaro principo pavyzdys gali būti suprantamas naršyklių pagalba. Ar prisimenate, kad įdiegėte plėtinius savo „Chrome“ naršyklėje?

Pagrindinė „Chrome“ naršyklės funkcija yra naršyti skirtingose ​​svetainėse. Ar norite patikrinti gramatiką, kai rašote el. Laišką naudodami „Chrome“ naršyklę? Jei taip, galite tiesiog naudoti „Grammarly“ plėtinį, kuris suteikia jums gramatikos turinio patikrinimą.

Šis mechanizmas, į kurį pridedate dalykų, kad padidintumėte naršyklės funkcionalumą, yra plėtinys. Taigi naršyklė yra puikus funkcionalumo pavyzdys, kuris yra atviras išplėtimui, bet uždarytas modifikuoti. Paprastais žodžiais tariant, galite pagerinti funkcionalumą pridėdami / įdiegdami papildinius savo naršyklėje, tačiau negalite sukurti nieko naujo.

Kodėl reikalingas šis principas?

OCP yra svarbu, nes pamokos gali ateiti pas mus per trečiųjų šalių bibliotekas. Turėtume sugebėti pratęsti šias klases nesijaudindami, ar tos bazinės klasės gali palaikyti mūsų pratęsimus. Tačiau paveldėjimas gali sukelti poklasius, kurie priklauso nuo bazinės klasės įgyvendinimo. Norėdami to išvengti, rekomenduojama naudoti sąsajas. Ši papildoma abstrakcija sukelia laisvą sujungimą.

Sakysime, kad turime apskaičiuoti įvairių formų plotus. Pradedame nuo pirmosios formos stačiakampio klasės sukūrimokuris turi 2 atributų ilgį& plotis.

public class Stačiakampis {public double length public double width}

Tada sukursime klasę, kad apskaičiuotume šio stačiakampio plotąkuris turi metodą apskaičiuoti stačiakampio plotąkuris užima Stačiakampįkaip įvesties parametrą ir apskaičiuoja jo plotą.

public class AreaCalculator {public double apskaičiuotiRectangleArea (Stačiakampio stačiakampis) {return rectangle.length * rectangle.width}}

Kol kas viskas gerai. Tarkime, kad gauname antrosios formos apskritimą. Taigi mes greitai sukuriame naują klasės ratąsu vienu atributo spinduliu.

viešosios klasės ratas {public double radius}

Tada mes modifikuojame „Areacalculator“klasė pridėti apskritimo skaičiavimus nauju metodu apskaičiuoti CircleeaArea ()

viešoji klasė „AreaCalculator“ {viešas dvigubas skaičiavimasTečiakampio plotas (stačiakampio stačiakampis) {grįžtamasis stačiakampis. ilgis * stačiakampis. plotis} viešasis dvigubas apskaičiavimo rato plotas (apskritimo apskritimas) {grįžimas (22/7) * apskritimas.radiusas * apskritimas.radius}}

Tačiau atkreipkite dėmesį, kad aukščiau pateiktame sprendime buvo trūkumų.

Sakykime, kad turime naujos formos penkiakampį. Tokiu atveju mes vėl pakeisime „AreaCalculator“ klasę. Augant figūrų tipams, tai tampa vis blogiau, nes „AreaCalculator“ keičiasi, o visi šios klasės vartotojai turės nuolat atnaujinti savo bibliotekas, kuriose yra „AreaCalculator“. Dėl to „AreaCalculator“ klasė nebus pagrindinė (galutinė) garantija, nes kaskart, kai atsiras nauja forma, ji bus modifikuojama. Taigi, šis dizainas nėra uždarytas modifikuoti.

„AreaCalculator“ turės pridėti savo skaičiavimo logiką naujesniais metodais. Mes iš tikrųjų neišplečiame formų apimties, o tiesiog darome kiekvienos pridedamos formos (po truputį) tirpalą.

Ankstesnio dizaino modifikavimas, kad atitiktų atidaryto / uždaro principą:

Dabar pamatykime elegantiškesnį dizainą, kuris pašalina aukščiau pateikto dizaino trūkumus, laikydamasis „Atviras / uždaras“ principo. Visų pirma padarysime dizainą išplečiamą. Tam pirmiausia turime apibrėžti pagrindo tipo formą ir turėti apskritimo ir stačiakampio formos sąsają.

viešoji sąsaja Forma {public double apskaičiuoti plotą ()} public class Stačiakampio formos Shape {dvigubo ilgio dvigubo pločio public double apskaičiavimo sritis () {return length * plot}}} public class Circle įgyvendina formą {public double radius public double apskaičiuoti plotą () {return (22 / 7) * spindulys * spindulys}}

Yra pagrindinė sąsajos forma. Visos formos dabar įgyvendina pagrindinės sąsajos formą. Formos sąsajoje yra abstraktus metodas apskaičiuoti plotą (). Tiek apskritimas, tiek stačiakampis pateikia savo nepaisomą „calcArea“ () metodo įgyvendinimą, naudodami savo atributus.
Mes atnešėme tam tikrą išplėtimo laipsnį, nes formos dabar yra „Shape“ sąsajų pavyzdys. Tai leidžia mums naudoti „Shape“ vietoj atskirų klasių
Paskutinis aukščiau paminėtas šių formų vartotojas. Mūsų atveju vartotojas bus „AreaCalculator“ klasė, kuri dabar atrodys taip.

public class AreaCalculator {public dvigubai apskaičiuotiShapeArea (formos forma) {return shape.calculateArea ()}}

Šis „AreaCalculator“klasė dabar visiškai pašalina aukščiau nurodytus mūsų dizaino trūkumus ir pateikia švarų sprendimą, kuris laikosi atviro uždarymo principo. Pereikime prie kitų „Java“ SOLID principų

Liskovo pakeitimo principas „Java“

Robertas C. Martinas apibūdina, kad išvestiniai tipai turi būti visiškai pakeisti jų pagrindiniais tipais.

Liskovo pakeitimo principas daro prielaidą, kad q (x) yra savybė, įrodoma apie x tipui priklausančius objektus, priklausančius T tipui. Dabar pagal šį principą q (y) dabar turėtų būti įrodyta objektams y, kurie priklauso S tipui, ir S iš tikrųjų yra T. potipis. Ar dabar esate sutrikęs ir nežinote, ką iš tikrųjų reiškia Liskovo pakeitimo principas? Jo apibrėžimas gali būti šiek tiek sudėtingas, bet iš tikrųjų tai gana lengva. Vienintelis dalykas yra tas, kad kiekvienas poklasis ar išvestinė klasė turėtų būti pakeičiami savo pagrindine ar pagrindine klase.

Galima sakyti, kad tai yra unikalus į objektą orientuotas principas. Principą gali dar labiau supaprastinti konkretaus tipo vaikų tipas, nesukeliant jokių komplikacijų ar nesprogdinant dalykų, turėtų turėti galimybę pasisakyti už tą tėvą. Šis principas yra glaudžiai susijęs su Liskovo pakeitimo principu.

Kodėl reikalingas šis principas?

Taip išvengiama netinkamo paveldėjimo naudojimo. Tai padeda mums atitikti „yra“ santykius. Taip pat galime pasakyti, kad poklasiai turi įvykdyti sutartį, kurią apibrėžia pagrindinė klasė. Šia prasme tai susiję suProjektavimas pagal sutartįtą pirmą kartą aprašė Bertrandas Meyeris. Pavyzdžiui, norisi pasakyti, kad apskritimas yra elipsės rūšis, tačiau apskritimai neturi dviejų židinių ar didžiųjų / mažųjų ašių.

LSP populiariai paaiškinama naudojant kvadrato ir stačiakampio pavyzdį. jei prisiimame ISA santykį tarp Kvadrato ir Stačiakampio. Taigi mes vadiname „Kvadratas yra stačiakampis“. Žemiau pateiktas kodas nurodo ryšį.

public class Stačiakampis {private int length private int width public int getLength () {return length} public void setLength (int length) {this.length = length} public int getBreadth () {return width} public void setBreadth (int width) { this.breadth = width} public int getArea () {return this.length * this.breadth}}

Žemiau yra „Square“ kodas. Atkreipkite dėmesį, kad kvadratas tęsiasi stačiakampį.

viešosios klasės kvadratas tęsiasi stačiakampis {public void setBreadth (int widthth) {super.setBreadth (width) super.setLength (width)} public void setLength (int length) {super.setLength (length) super.setBreadth (length)}}

Šiuo atveju mes bandome užmegzti ISA ryšį tarp „Square“ ir „Stačiakampio“ taip, kad paskambinus „Square is a Rectangle“ žemiau esančiame kode netikėtai imtųsi elgtis, jei būtų perduotas „Square“ egzempliorius. Tikrinant „Plotas“ ir „Plotis“, bus išmestas tvirtinimo klaida, nors programa bus nutraukta, nes tvirtinimo klaida bus išmesta dėl to, kad nepavyko patikrinti ploto.

viešoji klasė LSPDemo {public void apskaičiuoti plotas (stačiakampis r) {r.setBreadth (2) r.setLength (3) teigia r.getArea () == 6: printError ('area', r) teigia r.getLength () == 3: printError ('length', r) teigia r.getBreadth () == 2: printError ('width', r)} private String printError (String errorIdentifer, Rectectle r) {return 'Netikėta' + errorIdentifer + 'vertė pvz., „+ r.getClass (). getName ()} public static void main (String [] args) {LSPDemo lsp = new LSPDemo () // Stačiakampio egzempliorius perduodamas lsp.calculateArea (naujas stačiakampis ()) // Kvadrato egzempliorius perduodamas lsp.calculateArea (new Square ())}}

Klasė demonstruoja Liskovo pakeitimo principą (LSP) Pagal principą funkcijos, naudojančios nuorodas į pagrindines klases, turi sugebėti naudoti išvestinės klasės objektus to nežinodami.

Taigi toliau pateiktame pavyzdyje funkcija „apskaičiuoti plotą“, naudojant nuorodą „Stačiakampis“, turėtų sugebėti naudoti išvestinės klasės objektus, tokius kaip Kvadratas, ir atitikti stačiakampio apibrėžimo keliamus reikalavimus. Reikėtų pažymėti, kad atsižvelgiant į stačiakampio apibrėžimą, atsižvelgiant į toliau pateiktus duomenis, visada turi būti laikomasi šių principų:

1. Ilgis visada turi būti lygus ilgiui, perduotam kaip metodo „setLength“ įvestis
2. Plotis visada turi būti lygus plotiui, perduotam kaip metodo „setBreadth“ įvestis
3. Plotas visada turi būti lygus ilgio ir pločio sandaugai

Tuo atveju mes bandome užmegzti ISA ryšį tarp Kvadrato ir Stačiakampio, kurį vadiname „Kvadratas yra stačiakampis“. Jei praeis kvadrato egzempliorius, aukščiau pateiktas kodas pradės elgtis netikėtai. Patikrinus plotą ir patikrinant, bus padaryta teiginio klaida. pločio, nors programa bus nutraukta, nes teigiama klaida dėl srities patikrinimo gedimo.

„Square“ klasei nereikia tokių metodų kaip „setBreadth“ ar „setLength“. LSPDemo klasei reikia žinoti išsamią stačiakampio (pvz., Kvadrato) klasių informaciją, kad būtų galima tinkamai koduoti, kad būtų išvengta metimo klaidų. Esamo kodo pakeitimas visų pirma laužo atviro-uždaro principą.

Sąsajos atskyrimo principas

Robertas C. Martinas apibūdina, kad klientai neturėtų būti verčiami įgyvendinti nereikalingus metodus, kurių jie nenaudos.

PagalSąsajos atskyrimo principasklientas, nesvarbu, ko niekada nereikėtų priversti įdiegti sąsajos, kurios jis nenaudoja, arba klientas niekada neturėtų būti įpareigotas priklausyti nuo bet kokio metodo, kurio jie nenaudoja. Taigi, iš esmės, sąsajos atskyrimo principai, kaip jums labiau patinka sąsajos, kurios yra mažos, bet skirtos klientui, o ne monolitinei ir didesnei sąsajai. Trumpai tariant, jums būtų blogai priversti klientą priklausyti nuo tam tikro dalyko, kurio jiems nereikia.

Pavyzdžiui, viena registravimo sąsaja žurnalams rašyti ir skaityti yra naudinga duomenų bazei, bet ne konsolei. Žurnalų skaitymas nėra prasmės pulto žurnalistui. Toliau naudodamiesi „SOLID Principai“ „Java“ straipsnyje.

Kodėl reikalingas šis principas?

Sakykime, kad yra restorano sąsaja, kurioje pateikiami metodai, kaip priimti užsakymus iš internetinių klientų, telefono skambučių ar telefonų klientų ir klientų, kurie eina. Jame taip pat pateikiami metodai, kaip tvarkyti mokėjimus internetu (klientams internetu) ir mokėjimus asmeniškai (klientams, kurie eina, taip pat telefonu, kai jų užsakymas pristatomas namuose).

Dabar sukurkime „Java“ sąsają restoranui ir pavadinkime jį „RestaurantInterface.java“.

viešoji sąsaja „RestaurantInterface“ {public void acceptOnlineOrder () public void takeTelephoneOrder () public void payOnline () public void walkInCustomerOrder () public void payInPerson ()}

„RestaurantInterface“ yra apibrėžti 5 būdai, kaip priimti internetinį užsakymą, priimti telefoninį užsakymą, priimti užsakymus iš kliento, priimti mokėjimą internetu ir priimti asmeniškai.

Pradėkime įdiegdami „RestaurantInterface“ internetiniams klientams kaip „OnlineClientImpl.java“

viešoji klasė „OnlineClientImpl“ įgyvendina „RestaurantInterface“ {public void acceptOnlineOrder () {// internetinių užsakymų pateikimo logika} public void takeTelephoneOrder () {// Netaikoma internetiniam užsakymui, metant naują „UnsupportedOperationException ()} public void payOnline () {// mokėjimo logika internetinis} public void walkInCustomerOrder () {// Netaikoma internetiniam užsakymui išleisti naują UnsupportedOperationException ()} public void payInPerson () {// Netaikoma internetiniam užsakymui mesti naują UnsupportedOperationException ()}}

• Kadangi aukščiau pateiktas kodas (OnlineClientImpl.java) skirtas internetiniams užsakymams, meskite „UnsupportedOperationException“.

• Internetiniai, telefoniniai ir „walk-in“ klientai naudoja kiekvienam iš jų pritaikytą „RestaurantInterface“.

• „Telephonic“ kliento ir „Walk-in“ kliento įgyvendinimo klasėse bus nepalaikomi metodai.

• Kadangi 5 metodai yra „RestaurantInterface“ dalis, įgyvendinimo klasės turi įgyvendinti visus 5 iš jų.

• Metodai, kuriuos kiekviena įgyvendinimo klasė išmeta „UnsupportedOperationException“. Kaip aiškiai matote - įgyvendinti visus metodus yra neefektyvu.

• Bet kokie „RestaurantInterface“ metodų pakeitimai bus pritaikyti visoms įgyvendinimo klasėms. Tada kodo priežiūra tampa tikrai sudėtinga, o regresijos pokyčių poveikis vis didės.

  vaizdinės studijos pamokos pradedantiesiems

• „RestaurantInterface.java“ pažeidžia vienos atsakomybės principą, nes mokėjimų ir užsakymo pateikimo logika yra sugrupuota į vieną sąsają.

Norėdami įveikti pirmiau minėtas problemas, mes pritaikome sąsajos atskyrimo principą, kad pertvarkytume aukščiau pateiktą dizainą.

1. Atskirkite mokėjimo ir užsakymo pateikimo funkcijas į dvi atskiras „lean“ sąsajas - „PaymentInterface.java“ ir „OrderInterface.java“.

2. Kiekvienas iš klientų naudoja po vieną „PaymentInterface“ ir „OrderInterface“ diegimą. Pavyzdžiui - OnlineClient.java naudoja „OnlinePaymentImpl“ ir „OnlineOrderImpl“ ir pan.

3. Dabar bendros atsakomybės principas pridedamas kaip mokėjimo sąsaja (PaymentInterface.java) ir užsakymo sąsaja (OrderInterface).

4. Bet kurios užsakymo ar mokėjimo sąsajos pakeitimas neturi įtakos kitai. Dabar jie yra nepriklausomi. Nebereikės atlikti jokių manekenių ar mesti „UnsupportedOperationException“, nes kiekvienoje sąsajoje yra tik metodai, kuriuos ji visada naudos.

Pritaikius IPT

Priklausomybės keitimo principas

Robertas C. Martinas apibūdina tai, nes tai priklauso nuo abstrakcijų, o ne nuo konkretizacijų. Pagal jį aukšto lygio modulis niekada neturi remtis jokiu žemo lygio moduliu. pavyzdžiui

Einate į vietinę parduotuvę ko nors nusipirkti ir nusprendžiate už tai sumokėti naudodamiesi debeto kortele. Taigi, atiduodant kortelę tarnautojui, kad jis atliktų mokėjimą, tarnautojas nesivargina patikrinti, kokią kortelę davėte.

Net jei jūs davėte „Visa“ kortelę, jis neišdės „Visa“ automato, kad perbrauktų jūsų kortelę. Kredito kortelės ar debeto kortelės, kurią mokate, rūšiai net nesvarbu, jos paprasčiausiai ją perbrauks. Taigi šiame pavyzdyje galite pamatyti, kad tiek jūs, tiek tarnautojas esate priklausomi nuo kreditinės kortelės ištraukimo ir jūs nesijaudinate dėl kortelės specifikos. Tai yra priklausomybės inversijos principas.

Kodėl reikalingas šis principas?

Tai leidžia programuotojui pašalinti sunkiai užkoduotas priklausomybes, kad programa taptų laisvai sujungta ir išplėstinė.

viešoji klasė Studentas {privataus adreso adresas public studentas () {address = naujas adresas ()}}

Pirmiau pateiktame pavyzdyje Studentų klasei reikalingas objektas Adresas ir ji yra atsakinga už objekto Adresas inicijavimą ir naudojimą. Jei ateityje adreso klasė bus pakeista, mes taip pat turėsime atlikti pakeitimus Studentų klasėje. Tai leidžia glaudžiai susieti studentų ir adresų objektus. Šią problemą galime išspręsti naudodami priklausomybės inversijos dizaino modelį. y. adreso objektas bus įgyvendintas savarankiškai ir bus pateiktas Studentui, kai studentas bus išaiškintas naudojant konstruktoriaus ar nustatytojo priklausomybės inversiją.

Tuo mes baigėme šiuos SOLID principus „Java“.

Patikrinkite sukūrė patikima internetinė mokymosi įmonė „Edureka“, turinti daugiau nei 250 000 patenkintų besimokančiųjų tinklą visame pasaulyje. „Edureka“ „Java J2EE“ ir SOA mokymo ir sertifikavimo kursai yra skirti studentams ir specialistams, norintiems būti „Java“ kūrėjais. Kursas sukurtas tam, kad galėtumėte pradėti žvalgytis į „Java“ programavimą ir išmokyti pagrindines ir pažangesnes „Java“ koncepcijas kartu su įvairiomis „Java“ sistemomis, tokiomis kaip „Hibernate & Spring“.

Turite mums klausimą? Prašau tai paminėti šio tinklaraščio „SOLID principai„ Java “komentarų skiltyje, ir mes kuo greičiau susisieksime su jumis.