Programmatūras izstrādē, Uz objektu orientēts dizains ir izšķiroša loma elastīga, mērogojama, uzturējama un atkārtoti lietojama koda rakstīšanā. OOD izmantošanai ir tik daudz priekšrocību, taču ikvienam izstrādātājam ir jāzina arī SOLID princips labam objektorientētam programmēšanas dizainam. SOLID principu ieviesa Roberts C. Mārtins, pazīstams arī kā tēvocis Bobs, un tas ir programmēšanas kodēšanas standarts. Šis princips ir piecu tālāk norādīto principu saīsinājums.

• Vienas atbildības princips (SRP)
• Atvērtais/slēgts princips
• Liskova aizstāšanas princips (LSP)
• Interfeisa segregācijas princips (ISP)
• Atkarības inversijas princips (DIP)

SOLID princips palīdz samazināt ciešu savienojumu. Stingra saikne nozīmē, ka klašu grupa ir ļoti atkarīga viena no otras, no kā jums vajadzētu izvairīties savā kodā.

• Pretstatā ciešam savienojumam ir brīva savienošana, un jūsu kods tiek uzskatīts par labu kodu, ja tam ir brīvi savienotas klases.
• Brīvi saistītās klases samazina izmaiņas kodā, palīdz padarīt kodu vairāk lietojamu, apkopējamu, elastīgāku un stabilāku. Tagad apspriedīsim šos principus pa vienam…

1. Vienotās atbildības princips

Šis princips nosaka, ka Klasei vajadzētu būt tikai vienam iemeslam mainīties kas nozīmē, ka katrai klasei ir jābūt vienai atbildībai vai vienam darbam, vai vienam mērķim. Citiem vārdiem sakot, klasei programmatūras sistēmā vajadzētu būt tikai vienam darbam vai mērķim.

Šarvananda

Izpratīsim vienas atbildības principu, izmantojot piemēru:

Iedomājieties maiznieku, kurš ir atbildīgs par maizes cepšanu. Maiznieka uzdevums ir koncentrēties uz maizes cepšanu, nodrošinot, ka maize ir kvalitatīva, pareizi izcepta un atbilst maizes standartiem.

• Tomēr, ja maiznieks ir atbildīgs arī par krājumu pārvaldību, preču pasūtīšanu, klientu apkalpošanu un maizes ceptuves tīrīšanu, tas pārkāptu SRP.
• Katrs no šiem uzdevumiem ir atsevišķa atbildība, un, tos apvienojot, maiznieka uzmanība un efektivitāte maizes cepšanā var tikt apdraudēta.
• Lai ievērotu SRP, maiznīca varētu piešķirt dažādas lomas dažādām personām vai komandām. Piemēram, var būt atsevišķa persona vai komanda, kas ir atbildīga par krājumu pārvaldību, cita par izejvielu pasūtīšanu, cita par klientu apkalpošanu un cita par maizes ceptuves tīrīšanu.

2. Atvērtā/slēgtā princips

Šis princips nosaka, ka Programmatūras entītijām (klasēm, moduļiem, funkcijām utt.) jābūt atvērtām paplašināšanai, bet slēgtām modificēšanai kas nozīmē, ka jums vajadzētu būt iespējai paplašināt klases uzvedību, to nemainot.

Izpratīsim atvērto/slēgto principu, izmantojot piemēru:

Iedomājieties, ka jums ir klase ar nosaukumuPaymentProcessor>kas apstrādā maksājumus par tiešsaistes veikalu. Sākotnēji,PaymentProcessor>klase atbalsta tikai maksājumu apstrādi, izmantojot kredītkartes. Tomēr vēlaties paplašināt tā funkcionalitāti, lai atbalstītu arī maksājumu apstrādi, izmantojot PayPal.

Tā vietā, lai pārveidotu esošoPaymentProcessor>klasē, lai pievienotu PayPal atbalstu, varat izveidot jaunu klasi ar nosaukumuPayPalPaymentProcessor>kas paplašinaPaymentProcessor>klasē. Tādā veidā,PaymentProcessor>klase paliek slēgta modifikācijām, bet atvērta paplašināšanai, ievērojot Open-Closed principu

kā es varu jaunināt java

3. Liskova aizstāšanas princips

Principu ieviesa Barbara Liskova 1987. gadā un saskaņā ar šo principu Atvasinātajām vai pakārtotajām klasēm ir jābūt aizvietojamām ar savām pamata vai vecākklasēm . Šis princips nodrošina, ka jebkurai klasei, kas ir vecākklases atvase, ir jābūt izmantojamai tās vecāka vietā bez neparedzētas uzvedības.

java kartes piemērs

Sapratīsim Liskova aizstāšanas principu, izmantojot piemēru:

Viens no klasiskajiem šī principa piemēriem ir taisnstūris ar četrām malām. Taisnstūra augstums var būt jebkura vērtība, un platums var būt jebkura vērtība. Kvadrāts ir taisnstūris ar vienādu platumu un augstumu. Tātad mēs varam teikt, ka mēs varam paplašināt taisnstūra klases īpašības kvadrātu klasē.

Lai to izdarītu, ir jāmaina atvasinātā (kvadrātveida) klase ar vecāku (taisnstūra) klasi, lai tā atbilstu kvadrāta definīcijai ar četrām vienādām malām, bet atvasinātā klase neietekmē vecākklases uzvedību, tādēļ, ja jūs to darīsit ka tas pārkāps Liskova aizstāšanas principu.

4. Interfeisa segregācijas princips

Šis princips ir pirmais princips, kas attiecas uz saskarnēm, nevis klasēm programmā SOLID, un tas ir līdzīgs vienotās atbildības principam. Tajā teikts, ka nepiespiediet nevienu klientu ieviest saskarni, kas viņiem nav svarīga . Šeit jūsu galvenais mērķis ir koncentrēties uz to, lai izvairītos no intensīvas saskarnes, un dot priekšroku daudzām mazām, klientam raksturīgām saskarnēm. Jums vajadzētu dot priekšroku daudzām klientu saskarnēm, nevis vienai vispārējai saskarnei, un katrai saskarnei ir jābūt noteiktai atbildībai.

Sapratīsim saskarnes segregācijas principu, izmantojot piemēru:

konvertēt no char uz int java

Pieņemsim, ja jūs ieejat restorānā un esat tīrs veģetārietis. Viesmīlis šajā restorānā jums iedeva ēdienkarti, kurā ir iekļauti veģetārie produkti, ne-veģetārie produkti, dzērieni un saldumi.

• Šajā gadījumā jums kā klientam ir jābūt ēdienkartei, kurā ir iekļauti tikai veģetārie ēdieni, nevis viss, ko savā ēdienā neēdat. Šeit ēdienkartei jābūt atšķirīgai dažāda veida klientiem.
• Kopējo vai vispārīgo izvēlnes karti ikvienam var sadalīt vairākās kartēs, nevis tikai vienā. Šī principa izmantošana palīdz samazināt blakusparādības un nepieciešamo izmaiņu biežumu.

5. Atkarības inversijas princips

Atkarības inversijas princips (DIP) ir objektorientētā dizaina princips, kas to nosaka Augsta līmeņa moduļiem nevajadzētu būt atkarīgiem no zema līmeņa moduļiem. Abiem jābūt atkarīgiem no abstrakcijām . Turklāt abstrakcijas nedrīkst būt atkarīgas no detaļām. Detaļai jābūt atkarīgai no abstrakcijām.

• Vienkāršāk sakot, DIP iesaka klasēm paļauties uz abstrakcijām (piemēram, saskarnēm vai abstraktām klasēm), nevis uz konkrētām implementācijām.
• Tas nodrošina elastīgāku un atsaistītāku kodu, atvieglojot ieviešanas maiņu, neietekmējot citas kodu bāzes daļas.

Izpratīsim atkarības inversijas principu, izmantojot piemēru:

Programmatūras izstrādes komandā izstrādātāji ir atkarīgi no abstraktas versiju kontroles sistēmas (piemēram, Git), lai pārvaldītu un izsekotu kodu bāzes izmaiņas. Tie nav atkarīgi no konkrētām detaļām par to, kā Git darbojas iekšēji.

Tas ļauj izstrādātājiem koncentrēties uz koda rakstīšanu, neizprotot versiju kontroles ieviešanas sarežģītību.