Gana dažnai sutinku kūrėjus, kurie nėra girdėję apie SOLID principus (mes . — Vertimas) arba objektinį programavimą (OOP), arba girdėjote apie juos, bet praktiškai nenaudojate. Šiame straipsnyje aprašomi OOP principų pranašumai, padedantys kūrėjui kasdieniame darbe. Kai kurie iš jų žinomi gerai, kiti nelabai, todėl straipsnis bus naudingas tiek pradedantiesiems, tiek patyrusiems programuotojams.
Primename: visiems Habr skaitytojams - 10 000 rublių nuolaida registruojantis į bet kurį Skillbox kursą naudojant Habr reklamos kredito kodą.
„Skillbox“ rekomenduoja: Mokomasis internetinis kursas .
DRY (nekartokite savęs)
Gana paprastas principas, kurio esmė aiški iš pavadinimo: „Nekartok savęs“. Programuotojui tai reiškia poreikį vengti pasikartojančio kodo, taip pat galimybę savo darbe naudoti abstrakciją.
Jei kode yra du pasikartojantys skyriai, jie turėtų būti sujungti į vieną metodą. Jei užkoduota reikšmė naudojama daugiau nei vieną kartą, verta ją konvertuoti į viešą konstantą.
Tai būtina norint supaprastinti kodą ir palengvinti jo priežiūrą, o tai yra pagrindinis OOP tikslas. Taip pat neturėtumėte per daug naudoti sąjungos, nes tas pats kodas nebus patvirtintas nei užsakymo ID, nei SSN.
Pakeitimų inkapsuliavimas
Daugumos įmonių programinės įrangos produktai nuolat tobulinami. Tai reiškia, kad reikia atlikti kodo pakeitimus, jį reikia palaikyti. Naudodami kapsuliavimą galite palengvinti savo gyvenimą. Tai leis efektyviau išbandyti ir prižiūrėti esamą kodų bazę. .
Jei rašote Java, tada .
Atviro/uždarymo principas
Šį principą galima lengvai prisiminti perskaičius tokį teiginį: „Programinės įrangos subjektai (klasės, moduliai, funkcijos ir kt.) turėtų būti atviri išplėsti, bet uždaryti modifikavimui. Praktiškai tai reiškia, kad jie gali leisti keisti savo elgesį nekeičiant šaltinio kodo.
Principas yra svarbus, kai pakeitus šaltinio kodą reikia peržiūrėti kodą, išbandyti vienetus ir atlikti kitas procedūras. Kodas, kuris vadovaujasi atvirumo/uždarymo principu, pratęsus nesikeičia, todėl su juo problemų kyla daug mažiau.
Štai kodo, kuris pažeidžia šį principą, pavyzdys.
Jei jums reikės ką nors jame pakeisti, tai užtruks daug laiko, nes reikės pakeisti visas kodo dalis, turinčias ryšį su norimu fragmentu.
Beje, atvirumas-uždarumas yra vienas iš SOLID principų.
Vienos atsakomybės principas (SRP)
Kitas principas iš SOLID rinkinio. Jame teigiama, kad „yra tik viena priežastis, dėl kurios keičiasi klasė“. Klasė išsprendžia tik vieną problemą. Jis gali turėti kelis metodus, tačiau kiekvienas iš jų naudojamas tik bendrai problemai išspręsti. Visi metodai ir savybės turėtų tarnauti tik tam.
Šio principo vertė yra ta, kad jis atlaisvina ryšį tarp atskiro programinės įrangos komponento ir kodo. Jei prie klasės pridedate daugiau nei vieną funkciją, tai sukuria ryšį tarp dviejų funkcijų. Taigi, jei pakeisite vieną iš jų, yra didelė tikimybė sugadinti antrąjį, kuris yra prijungtas prie pirmojo. Tai reiškia, kad reikia padidinti bandymų ciklus, kad būtų iš anksto nustatytos visos problemos.
Priklausomybės inversijos principas (DIP)
Aukščiau pateiktas kodo pavyzdys, kuriame AppManager priklauso nuo EventLogWriter, kuris savo ruožtu yra glaudžiai susijęs su AppManager. Jei jums reikia kitokio pranešimo rodymo būdo, nesvarbu, ar tai būtų tiesioginis, SMS ar el. paštas, turite pakeisti „AppManager“ klasę.
Problemą galima išspręsti naudojant DIP. Taigi vietoj AppManager prašome EventLogWriter, kuris bus įvestas naudojant sistemą.
DIP leidžia lengvai pakeisti atskirus modulius kitais, keičiant priklausomybės modulį. Tai leidžia pakeisti vieną modulį nepažeidžiant kitų.
Sudėtis vietoj paveldėjimo
Yra du pagrindiniai kodo pakartotinio naudojimo būdai: paveldėjimas ir sudėtis, kurie abu turi savų privalumų ir trūkumų. Paprastai pirmenybė teikiama antrajam, nes jis yra lankstesnis.
Kompozicija suteikia galimybę keisti klasės elgesį vykdymo metu, nustatant jos savybes. Diegiant sąsajas naudojamas polimorfizmas, kuris suteikia lankstesnį įgyvendinimą.
Netgi Joshua Bloch „Efektyvi Java“ pataria rinktis kompoziciją, o ne paveldėjimą.
Barbaros Liskov pakeitimo principas (LSP)
Kitas SOLID įrankių rinkinio principas. Jame teigiama, kad potipiai turi būti pakeisti supertipu. Tai yra, metodai ir funkcijos, veikiantys su superklase, turėtų be problemų veikti su jos poklasiais.
LSP siejamas tiek su vienos atsakomybės, tiek su bendros atsakomybės principu. Jei klasė suteikia daugiau funkcijų nei poklasis, pastaroji nepalaikys kai kurių funkcijų, pažeidžiant šį principą.
Čia yra kodo dalis, kuri prieštarauja LSP.
Ploto (stačiakampio r) metodas apskaičiuoja stačiakampio plotą. Programa sugenda, kai bus vykdomas kvadratas, nes kvadratas čia nėra stačiakampis. Pagal LSP principą funkcijos, kurios naudoja nuorodas į bazines klases, turėtų turėti galimybę naudoti išvestinių klasių objektus be papildomų nurodymų.
Šį principą, kuris yra specifinis potipio apibrėžimas, pasiūlė Barbara Liskov 1987 m. konferencijos pagrindiniame pranešime pavadinimu „Duomenų abstrakcija ir hierarchija“, iš čia ir kilo jo pavadinimas.
Sąsajos padalijimo principas (ISP)
Dar vienas SOLID principas. Pagal ją nenaudojama sąsaja neturėtų būti įdiegta. Šio principo laikymasis padeda sistemai išlikti lanksčiai ir tinkamai pertvarkyti, kai keičiama veikimo logika.
Dažniausiai tokia situacija nutinka, kai sąsajoje vienu metu yra kelios funkcijos, o klientui reikia tik vienos iš jų.
Kadangi sąsajos rašymas yra sunki užduotis, ją pakeisti baigus darbą nieko nepažeidžiant bus iššūkis.
ISP principo Java programoje privalumas yra tas, kad visi metodai turi būti pirmiausia įdiegti, o tik tada juos gali naudoti klasės. Todėl principas leidžia sumažinti metodų skaičių.
Programavimas sąsajai, o ne įgyvendinimui
Viskas čia aišku iš pavadinimo. Taikant šį principą, sukuriamas lankstus kodas, kuris gali veikti su bet kokiu nauju sąsajos įgyvendinimu.
Turėtumėte naudoti sąsajos tipą kintamiesiems, grąžinimo tipams arba metodo argumento tipui. Pavyzdys yra SuperClass, o ne SubClass naudojimas.
Tai yra:
Sąrašo numeriai= getNumbers();
Bet ne:
ArrayList numeriai = getNumbers();
Čia yra praktinis aukščiau aptartų dalykų įgyvendinimas.
Delegavimo principas
Dažnas pavyzdys yra „Java“ metodai equals () ir hashCode (). Kai reikia palyginti du objektus, šis veiksmas deleguojamas atitinkamai klasei, o ne kliento klasei.
Šio principo pranašumas yra tas, kad nėra kodo dubliavimo ir gana paprasta pakeisti elgesį. Tai taip pat taikoma renginių delegavimui.
Visi šie principai leidžia parašyti lankstesnį, gražesnį ir patikimesnį kodą su didele sanglauda ir mažu sujungimu. Žinoma, teorija yra gerai, bet norint, kad kūrėjas realiai panaudotų įgytas žinias, reikia praktikos. Įvaldę OOP principus, kitas žingsnis gali būti išmokti projektavimo modelius, kad išspręstumėte įprastas programinės įrangos kūrimo problemas.
„Skillbox“ rekomenduoja:
- Praktinis kursas .
- Taikomas internetinis kursas .
- Dvejų metų praktinis kursas .
Šaltinis: www.habr.com