Pogosto srečam razvijalce, ki še niso slišali za načela SOLID (mi . — Prev.) ali objektno orientirano programiranje (OOP) ali pa ste zanje že slišali, vendar jih v praksi ne uporabljate. Ta članek opisuje prednosti načel OOP, ki razvijalcu pomagajo pri vsakodnevnem delu. Nekateri od njih so dobro znani, drugi manj, zato bo članek koristen tako za začetnike kot za izkušene programerje.
Spomnimo: za vse bralce Habra - 10 rubljev popusta pri vpisu v kateri koli tečaj Skillbox s promocijsko kodo Habr.
Skillbox priporoča: Izobraževalni spletni tečaj .
SUHO (ne ponavljaj se)
Precej preprosto načelo, katerega bistvo je jasno iz imena: "Ne ponavljaj se." Za programerja to pomeni potrebo po izogibanju podvojeni kodi, pa tudi možnost uporabe abstrakcije pri svojem delu.
Če sta v kodi dva ponavljajoča se odseka, ju je treba združiti v eno metodo. Če je trdo kodirana vrednost uporabljena več kot enkrat, jo je vredno pretvoriti v javno konstanto.
To je potrebno zaradi poenostavitve kode in lažjega vzdrževanja, kar je glavni cilj OOP. Prav tako ne smete pretiravati z zvezo, saj ista koda ne bo prestala preverjanja z OrderId in SSN.
Enkapsulacija sprememb
Programski izdelki večine podjetij se nenehno razvijajo. To pomeni, da je treba spremeniti kodo, jo je treba podpreti. Z uporabo enkapsulacije si lahko olajšate življenje. To vam bo omogočilo učinkovitejše testiranje in vzdrževanje vaše obstoječe baze kod. .
Če pišete v Javi, potem .
Odprto/zaprto načelo
To načelo si lahko zlahka zapomnite, če preberete naslednjo izjavo: "Entitete programske opreme (razredi, moduli, funkcije itd.) morajo biti odprte za razširitev, vendar zaprte za spreminjanje." V praksi to pomeni, da lahko dovolijo spreminjanje svojega vedenja brez spreminjanja izvorne kode.
Načelo je pomembno, kadar spremembe izvorne kode zahtevajo revizijo kode, testiranje enote in druge postopke. Koda, ki sledi principu odprto/zaprto, se ob razširitvi ne spremeni, zato je z njo veliko manj težav.
Tukaj je primer kode, ki krši to načelo.
Če morate v njem nekaj spremeniti, bo trajalo veliko časa, saj bo treba spremeniti vse dele kode, ki so povezani z želenim fragmentom.
Mimogrede, odprtost-zaprtost je eno od načel SOLID-a.
Načelo enotne odgovornosti (SRP)
Še en princip iz sklopa SOLID. Navaja, da "obstaja samo en vzrok, ki povzroči spremembo v razredu." Razred rešuje samo en problem. Lahko ima več metod, vendar se vsaka od njih uporablja samo za reševanje skupne težave. Vse metode in lastnosti naj služijo le temu.
Vrednost tega načela je v tem, da zrahlja povezavo med posamezno programsko komponento in kodo. Če razredu dodate več kot eno funkcionalnost, uvede razmerje med obema funkcijama. Torej, če spremenite enega od njih, obstaja velika možnost, da uničite drugega, ki je povezan s prvim. In to pomeni povečanje ciklov testiranja, da bi vnaprej prepoznali vse težave.
Načelo inverzije odvisnosti (DIP)
Zgoraj je primer kode, kjer je AppManager odvisen od EventLogWriter, ta pa je tesno povezan z AppManagerjem. Če potrebujete drugačen način za prikaz obvestila, bodisi potisno, SMS ali e-pošto, morate spremeniti razred AppManager.
Težavo je mogoče rešiti z DIP. Tako namesto AppManagerja zahtevamo EventLogWriter, ki bo vnesen z uporabo ogrodja.
DIP omogoča enostavno zamenjavo posameznih modulov z drugimi s spremembo modula odvisnosti. To omogoča spremembo enega modula, ne da bi to vplivalo na druge.
Sestava namesto dedovanja
Obstajata dva glavna načina za ponovno uporabo kode: dedovanje in sestavljanje, ki imata oba svoje prednosti in slabosti. Običajno je prednost druga, ker je bolj prilagodljiva.
Sestava vam omogoča, da spremenite vedenje razreda med izvajanjem z nastavitvijo njegovih lastnosti. Pri implementaciji vmesnikov se uporablja polimorfizem, ki daje bolj fleksibilno implementacijo.
Even Effective Java avtorja Joshue Blocha svetuje izbiro sestave namesto dedovanja.
Načelo zamenjave Barbare Liskov (LSP)
Še en princip iz kompleta orodij SOLID. Navaja, da morajo biti podtipi nadomestljivi za supertip. To pomeni, da bi morale metode in funkcije, ki delujejo z nadrazredom, brez težav delovati z njegovimi podrazredi.
LSP je povezan tako z načelom enotne odgovornosti kot z načelom deljene odgovornosti. Če razred zagotavlja več funkcionalnosti kot podrazred, potem slednji ne bo podpiral nekaterih funkcionalnosti, kar krši to načelo.
Tukaj je del kode, ki je v nasprotju z LSP.
Metoda area(Rectangle r) izračuna površino pravokotnika. Program se bo zrušil po izvedbi Square, ker Square tukaj ni pravokotnik. V skladu z načelom LSP bi morale funkcije, ki uporabljajo reference na osnovne razrede, imeti možnost uporabljati objekte izpeljanih razredov brez dodatnih navodil.
To načelo, ki je specifična definicija podtipa, je predlagala Barbara Liskov v osrednjem govoru na konferenci leta 1987 z naslovom »Abstrakcija podatkov in hierarhija«, od tod tudi njegovo ime.
Načelo ločevanja vmesnikov (ISP)
Še en SOLID princip. V skladu z njim vmesnik, ki se ne uporablja, ne bi smel biti implementiran. Upoštevanje tega načela pomaga sistemu, da ostane prilagodljiv in primeren za preoblikovanje, ko se spremeni logika delovanja.
Najpogosteje se ta situacija zgodi, ko vmesnik vsebuje več funkcij hkrati, odjemalec pa potrebuje samo eno od njih.
Ker je pisanje vmesnika težka naloga, bo spreminjanje vmesnika po končanem delu izziv.
Prednost principa ISP v Javi je, da je treba vse metode najprej implementirati in šele nato jih lahko uporabljajo razredi. Zato načelo omogoča zmanjšanje števila metod.
Programiranje za vmesnik, ne za izvedbo
Tukaj je vse jasno iz imena. Uporaba tega načela vodi do ustvarjanja prilagodljive kode, ki lahko deluje s katero koli novo implementacijo vmesnika.
Uporabite tip vmesnika za spremenljivke, povratne tipe ali tip argumenta metode. Primer je uporaba SuperClass namesto SubClass.
To se pravi:
Seznam številk= getNumbers();
Vendar ne:
ArrayList numbers = getNumbers();
Tukaj je praktična izvedba zgoraj omenjenega.
Načelo delegiranja
Pogost primer sta metodi equals() in hashCode() v Javi. Ko je treba primerjati dva objekta, se to dejanje prenese na ustrezen razred namesto na odjemalca.
Prednost principa je, da ni podvajanja kode in je razmeroma enostavno spremeniti vedenje. Velja tudi za delegiranje dogodkov.
Vsa ta načela vam omogočajo pisanje bolj prilagodljive, lepše in zanesljive kode z visoko kohezijo in nizkim spajanjem. Teorija je seveda dobra, a da razvijalec pridobljeno znanje dejansko uporabi, je potrebna praksa. Ko boste obvladali načela OOP, bo morda vaš naslednji korak učenje načrtovalskih vzorcev za reševanje pogostih težav pri razvoju programske opreme.
Skillbox priporoča:
- Praktični tečaj .
- Uporabni spletni tečaj .
- Dvoletni praktični tečaj .
Vir: www.habr.com