Kas ir SOLID principi?

SOLID principi ietver piecas pa­mat­nos­tād­nes, kas nodrošina tīru, viegli uzturamu un elastīgu kodu ob­jek­to­rien­tē­tā prog­ram­mē­ša­nā. Šo principu pie­mē­ro­ša­na un ie­vē­ro­ša­na nodrošina viegli saprotamu prog­ram­ma­tū­ras dizainu pat ilgstošas izstrādes laikā. Pa­tei­co­ties šiem prin­ci­piem, ne tikai var rakstīt labāku kodu, bet arī esošo kodu ir vieglāk uzturēt.

Kas ir SOLID principi un kas tos iz­strā­dā­ja?

Labs avota kods sākas ar no­tei­ku­miem, prog­ram­mē­ša­nas pa­ra­dig­mām un piemērotu prog­ram­mē­ša­nas stilu, kas nodrošina efektīvu un skaidru kodu. Tieši to garantē pieci SOLID principi, kurus iz­strā­dā­ja Roberts C. Martins, Bertrands Meijers un Barbara Liskova. Ievērojot šos principus ob­jek­to­rien­tē­tā prog­ram­mē­ša­nā (OOP) ar tādām valodām kā Python vai Java, jūs ne tikai rakstāt labāku kodu, bet arī no­dro­ši­nāt efek­tī­vā­ku koda uz­tu­rē­ša­nu, ilgtspē­jī­gu un elastīgu prog­ram­ma­tū­ras dizainu un lielāku drošību ilgter­mi­ņā.

Nosaukums SOLID simbolizē stingru prog­ram­mē­ša­nas pamatu, kas ne­pie­cie­šams ikvienam, kurš vēlas apgūt prog­ram­mē­ša­nu. Šo akronīmu izveidoja Maikls Feiterss, iz­man­to­jot katra no pieciem prin­ci­piem pirmos burtus:

• Vienas at­bil­dī­bas princips: klasei vajadzētu būt vienam un tikai vienam iemeslam, kāpēc tā jāmaina.
• At­vēr­tī­bas-slēgtības princips: Prog­ram­ma­tū­ras vienībām (klasēm, moduļiem, funkcijām utt.) jābūt atvērtām pa­pla­ši­nā­ša­nai, bet slēgtām mo­di­fi­kā­ci­jām.
• Liskovas aiz­stā­ja­mī­bas princips: ap­akš­kla­sēm jāspēj mantot un īstenot visas virskla­ses metodes un īpašības.
• Saskarnes no­šķir­ša­nas princips: saskarnēm ne­va­ja­dzē­tu saturēt vairāk metožu, nekā ne­pie­cie­šams klašu īs­te­no­ša­nai.
• Atkarības ap­grie­ša­nas princips: Klasēm ne­va­ja­dzē­tu būt atkarīgām no citām klasēm, bet gan no in­ter­fei­sēm vai abs­trak­tām klasēm.

Kādas priekš­ro­cī­bas sniedz SOLID principi?

Ja nav noteikumu, rodas haoss, un tas kļūst īpaši pamanāms prog­ram­mē­ša­nā. Pat nelielas kļūdas, ne­pre­ci­zi­tā­tes un ne­pil­nī­bas var padarīt labu avota kodu ilgter­mi­ņā pilnīgi ne­lie­to­ja­mu, ja tās netiek novērstas. Dažkārt pietiek ar sa­rež­ģī­tām klasēm, kas apgrūtina īs­te­no­ša­nu, vai ap­akš­kla­sēm, kurām trūkst virskla­ses in­di­vi­duā­lo īpašību. SOLID principi nodrošina, ka re­fak­to­ri­zā­ci­jas rezultātā jālabo pēc iespējas mazāk koda.

SOLID principi nosaka kodu:

• Skaidrs, pār­ska­tāms un pie­vil­cīgs: prog­ram­ma­tū­ra un kods ir vieglāk saprotams, efek­tī­vāks un vienkārši izskatās labāk.
• Viegli uzturams: vienkāršā un skaidrā struktūra atvieglo vairākiem sa­dar­bī­bas par­tne­riem gan jauna, gan esošā koda uz­tu­rē­ša­nu un pār­val­dī­bu.
• Pie­lā­go­jams, pa­pla­ši­nāms, atkārtoti iz­man­to­jams: pa­tei­co­ties uzlabotai lasāmībai, sa­ma­zi­nā­tai sa­rež­ģī­tī­bai un at­bil­dī­bai, kā arī mazākai atkarībai no klasēm, kodu var labāk rediģēt, pielāgot un pa­pla­ši­nāt, iz­man­to­jot saskarnes, un elastīgi atkārtoti izmantot.
• Mazāk pakļauts kļūdām: tīrs kods ar vienkāršu struktūru nozīmē, ka izmaiņas vienā koda daļā nejauši neietekmē citas jomas vai funkcijas.
• Drošs un uz­ti­ca­māks: samazinot vai novēršot ie­vai­no­ja­mī­bas, ne­sa­de­rī­bas un kļūdas, tiek uzlabota sistēmas fun­kcio­na­li­tā­te un uz­ti­ca­mī­ba, kas savukārt uzlabo drošību.

Ko nozīmē katrs no SOLID prin­ci­piem?

SOLID principi ir uzskatāmi par labas prog­ram­mē­ša­nas zelta likumiem, un tie būtu jāzina ikvienam, kurš no­dar­bo­jas ar ob­jek­to­rien­tē­tu prog­ram­mē­ša­nu. Tur­pi­nā­ju­mā mēs katru principu iz­skaid­ro­sim sīkāk.

SRP: Vienas at­bil­dī­bas princips

Roberts C. Martins iz­strā­dā­ja šī principa sākotnējo de­fi­nī­ci­ju grāmatā „Agile Software De­ve­lopment: Prin­ciples, Patterns and Practices“ (Ātrā prog­ram­ma­tū­ras izstrāde: principi, modeļi un prakse), rakstot:

Vienotās at­bil­dī­bas princips (SRP) nosaka, ka katrai klasei ob­jek­to­rien­tē­tā prog­ram­mē­ša­nā (OOP) vajadzētu būt tikai vienai at­bil­dī­bas jomai. Tas nozīmē, ka klases mo­di­fi­cē­ša­nai vajadzētu būt tikai vienam iemeslam. Pretēji iz­pla­tī­ta­jam uzskatam tas nenozīmē, ka klasei vai modulim var būt tikai tieši viens uzdevums. Drīzāk tas nozīmē, ka tai vajadzētu būt at­bil­dī­gai tikai par kon­krē­tiem uz­de­vu­miem, kuri ideālā gadījumā ne­pār­klā­jas ar citām jomām.

At­bil­dī­bas pār­klā­ša­nās, piemēram, funkciju no­dro­ši­nā­ša­na dažādiem biznesa seg­men­tiem, var ietekmēt klases fun­kcio­na­li­tā­ti, ja vienā segmentā tiek veiktas izmaiņas. Ja klasei ir vairākas at­bil­dī­bas un daudzas atkarības, viena izmaiņa vienā jomā var izraisīt kļūdas kodā vai ne­pie­cie­ša­mī­bu veikt papildu izmaiņas.

Vienotās at­bil­dī­bas princips (SRP) ir iz­strā­dāts, lai veidotu sa­ska­ņo­tus moduļus, kuriem uzticētas konkrētas, skaidri definētas funkcijas vai objekti. Pa­tei­co­ties tā skaid­ra­jai, struk­tu­rē­ta­jai uzbūvei ar minimālu atkarību skaitu un ne­at­ka­rī­gām īs­te­no­ju­miem, izmaiņas un pie­lā­go­ju­mus var veikt efektīvāk, ātrāk un vien­kār­šāk.

OCP: Atvērtā-slēgtā princips

Saskaņā ar Roberta C. Martina un Bertranda Meijera grāmatu „Ob­jek­to­rien­tē­ta prog­ram­ma­tū­ras izstrāde“ OCP nosaka:

OCP nodrošina, ka, lai ieviestu izmaiņas, nav ne­pie­cie­šams pār­rak­stīt prog­ram­ma­tū­ras kodola daļu. Ja ir ne­pie­cie­ša­mas pa­dzi­ļi­nā­tas izmaiņas kodā, pastāv risks, ka var rasties grūti pamanāmas kļūdas un „kodēšanas smaržas”. Labi struk­tu­rē­tam kodam ir jā­no­d­ro­ši­na saskarnes, kuras var izmantot, lai to pa­pla­ši­nā­tu ar papildu funkcijām. Galvenais jēdziens šeit ir klases pār­man­to­ša­na.

Jaunas funkcijas un pa­pla­ši­nā­ju­mi ar skaidri definētām jaunām funkcijām un metodēm, kuras ir jāievieš, var viegli pievienot virskla­sei, iz­man­to­jot in­ter­fei­su ap­akš­kla­ses veidā. Tādējādi nav ne­pie­cie­šams mainīt jau iz­strā­dā­to, stabilo kodu. Tas vienkāršo prog­ram­ma­tū­ras uz­tu­rē­ša­nu un apkopi, kā arī ie­vē­ro­ja­mi uzlabo stabilu koda elementu at­kār­to­tas iz­man­to­ša­nas efek­ti­vi­tā­ti, iz­man­to­jot in­ter­fei­sus.

LSP: Liskova aiz­vie­to­ša­nas princips

Kā norāda Barbara H. Liskov un Jeannette M. Wing rakstā „Uzvedības ap­akš­ti­pi­zā­ci­ja, iz­man­to­jot in­va­rian­tus un ie­ro­be­žo­ju­mus”, LSP nosaka, ka:

Tas var šķist neskaidrs, taču patiesībā tas ir diezgan viegli saprotams: saistītās vai pa­pla­ši­nā­tās ap­akš­kla­ses ir jā­dar­bo­jas tāpat kā to virskla­ses vai bāzes klases. Tas nozīmē, ka katrai ap­akš­kla­sei mantojuma ceļā ir jāsaglabā at­tie­cī­gās virskla­ses īpašības, un šīs īpašības ap­akš­kla­sē nedrīkst mainīt. Tām principā jābūt aiz­vie­to­ja­mām, no kā arī cēlies aiz­vie­to­ša­nas princips. Virskla­ses, savukārt, var tikt mainītas.

Lai to iz­skaid­ro­tu, aplūkosim Roberta C. Martina klasisko piemēru par taisn­stū­riem un kvad­rā­tiem. Ģeo­met­ri­jas stundās mēs apgūstam šādu principu: katrs kvadrāts ir taisn­stū­ris, bet ne katrs taisn­stū­ris ir kvadrāts. Kvadrātam ne tikai visas malas ir tais­nleņ­ķī­gas, tāpat kā taisn­stū­rim, bet arī visas tā malas ir vienāda garuma.

Prog­ram­mē­ša­nā pieņēmums, ka līdzīgas vai šķietami iden­tis­kas klases ir sav­star­pē­ji saistītas vai atkarīgas viena no otras, rada kļūdas, pār­pra­tu­mus un neskaidru kodu. Tāpēc prog­ram­mē­ša­nā klase „Rectangle” nav kvadrāts, un klase „Square” nav taisn­stū­ris. Abas ir atdalītas un īstenotas atsevišķi. Bez in­teg­rē­tas saiknes starp klasēm pār­pra­tu­mi nevar izraisīt kļūdas starp klasēm. Tas uzlabo drošību un sta­bi­li­tā­ti, mainot īs­te­no­ju­mus ap­akš­kla­sēs vai virskla­sēs, neradot nekādas sekas.

ISP: In­ter­fei­su no­šķir­ša­nas princips

Saskaņā ar Roberta C. Martina darbu „In­ter­fei­sa seg­re­gā­ci­jas princips“ (The Interface Seg­re­ga­tion Principle) ISP tiek definēts šādi:

ISP nosaka, ka lie­to­tā­jiem ne­va­ja­dzē­tu izmantot in­ter­fei­sus, kas viņiem nav ne­pie­cie­ša­mi. Citiem vārdiem sakot: lai no­dro­ši­nā­tu klientiem noteiktu klašu funkcijas, tiek iz­strā­dā­ti jauni, mazāki in­ter­fei­si, kas pielāgoti konkrētām prasībām. Tas novērš in­ter­fei­su pārmērīgu pa­pla­ši­nā­ša­nos un nodrošina, ka starp klasēm ne­vei­do­jas pārāk ciešas atkarības. Priekš­ro­cī­ba ir tāda, ka prog­ram­ma­tū­ru ar atdalītām klasēm un vairākiem maziem, konkrētām prasībām pie­lā­go­tiem in­ter­fei­siem ir vieglāk uzturēt.

DIP: Atkarību ap­grie­ša­nas princips

Saskaņā ar Roberta C. Martina iz­klās­tī­to grāmatā „The De­pen­dency Inversion Principle“ piektais un pēdējais no SOLID prin­ci­piem ir šāds:

DIP nodrošina, ka konkrētas funkcijas un atkarības avota koda slāņos balstās uz abs­trak­tām saskarnēm, nevis tieši viena no otras. Prog­ram­ma­tū­ras ar­hi­tek­tū­ras parasti tiek struk­tu­rē­tas augstākos lietotāju līmeņos un zemākos, abs­trak­tā­kos līmeņos. Loģiski varētu domāt, ka abs­trak­tais pamats ietekmē augstāko slāņu darbību. Tomēr DIP šeit norāda uz po­ten­ciā­lu problēmu, jo tas rada augstāko līmeņu atkarību no ze­mā­ka­jiem līmeņiem, kas var izraisīt problēmas.

Tā vietā, lai augstākie līmeņi būtu saistīti ar zemākiem līmeņiem, augstāko un zemāko līmeņu klasēm vajadzētu bal­stī­ties uz abs­trak­tām starplī­me­ņu saskarnēm. Šīs saskarnes iegūst no zemākiem līmeņiem funkcijas, kas ne­pie­cie­ša­mas augst­ā­ka­jos līmeņos, un nodrošina to pie­eja­mī­bu. Tādējādi var iz­vai­rī­ties no atkarību hie­rar­hi­jas, kas veidojas no apakšas uz augšu, jo tā laika gaitā var izraisīt kļūdas kodā. Tas veicina moduļu atkārtotu iz­man­to­ša­nu un ļauj veikt izmaiņas zemākajās klasēs, ne­ie­tek­mē­jot augstākos līmeņus.

Kas notiek, ja netiek ievēroti SOLID principi?

Tīra un pār­ska­tā­ma koda izstrāde, kas atvieglo tā uz­tu­rē­ša­nu, ir jāuzskata par galveno mērķi prog­ram­ma­tū­ras izstrādē. Ja iz­strā­dā­tā­ji neievēro būtiskas vadlī­ni­jas, piemēram, SOLID principus, koda kvalitāte var ie­vē­ro­ja­mi pa­slik­ti­nā­ties drošības risku, liekuma, uzkrāto kļūdu un pārmērīgu atkarību dēļ. Ekstrēmos gadījumos kods laika gaitā var kļūt ne­lie­to­jams. Tas ir būtisks jautājums ātrās prog­ram­ma­tū­ras izstrādē, kur sa­rež­ģī­tos prog­ram­mē­ša­nas uzdevumos bieži vien strādā daudzi cilvēki.

Nepareizi rakstīta koda vai ne­pie­tie­ka­mas koda uz­tu­rē­ša­nas sekas ir šādas:

• Koda „smakums“: ja kods nav rakstīts at­bil­sto­ši ne­pie­cie­ša­ma­jiem stan­dar­tiem, tas var izraisīt koda „smakumu“ jeb „smakojošu kodu“, kas savukārt var novest pie fun­kcio­nā­lām kļūdām un programmu ne­sa­de­rī­bas.
• Koda pūšana: ja kods netiek uzturēts vai labots, veicot re­fak­to­ri­zā­ci­ju vai dārgu koda pār­ska­tī­ša­nu, tas var fi­gu­ra­tī­vi „pūst” un pilnībā zaudēt savu fun­kcio­na­li­tā­ti. Cits termins, kas apzīmē ne­sap­ro­ta­mu, sarežģītu kodu, ir spageti kods.
• Drošības riski: Problēmas ne­ap­ro­be­žo­jas tikai ar darbības pār­trau­ku­miem, sarežģītu uz­tu­rē­ša­nu un saderības problēmām. Pastāv arī drošības ne­pil­nī­bas, kas ļaunprog­ram­ma­tū­rām sniedz iespējas izmantot kodu, tostarp „zero-day” eks­plua­tā­ci­jas.

Kas iz­strā­dā­ja SOLID principus?

SOLID principu izcelsme saistīta ar vairākiem prin­ci­piem, kurus 2000. gadā savā esejā „Design Prin­ciples and Design Patterns” pirmo reizi ieviesa Roberts C. Martins („Uncle Bob”), viens no ātrās prog­ram­mē­ša­nas ini­cia­to­riem. SOLID principus iz­strā­dā­ja Roberts C. Martins, Bertrands Meijers un Barbara Liskova. Šo viegli ie­gau­mē­ja­mo akronīmu po­pu­la­ri­zē­ja Maikls Feiters, kurš piecu būtisko principu sā­kum­bur­tus pār­kār­to­ja viegli ie­gau­mē­ja­mā secībā.

Kādi ir līdzīgi prog­ram­mē­ša­nas principi?

Prog­ram­ma­tū­ras izstrādē principi ir vis­pā­rī­gas vai ļoti konkrētas vadlī­ni­jas un ieteikumi rīcībai. Papildus SOLID prin­ci­piem, kas tika iz­strā­dā­ti ob­jek­to­rien­tē­ta­jai prog­ram­mē­ša­nai, citi prog­ram­mē­ša­nas principi tīra koda izstrādei ietver:

• DRY princips (Don’t repeat yourself) funkcijām ar vienu, unikālu izpausmi
• KISS princips (Keep it simple, stupid) kodam, kas veidots pēc iespējas vien­kār­šāk