Pri razvoju programske opreme, Objektno usmerjeno oblikovanje igra ključno vlogo, ko gre za pisanje prilagodljive, razširljive, vzdrževane in ponovno uporabne kode. Uporaba OOD ima toliko prednosti, vendar bi moral vsak razvijalec poznati tudi načelo SOLID za dobro objektno usmerjeno zasnovo v programiranju. Načelo SOLID je uvedel Robert C. Martin, znan tudi kot stric Bob, in je standard kodiranja v programiranju. To načelo je akronim petih spodaj navedenih načel:

• Načelo enotne odgovornosti (SRP)
• Odprto/zaprto načelo
• Liskovo substitucijsko načelo (LSP)
• Načelo ločevanja vmesnika (ISP)
• Načelo inverzije odvisnosti (DIP)

Načelo SOLID pomaga zmanjšati tesno spajanje. Tesna povezava pomeni, da je skupina razredov močno odvisna drug od drugega, čemur se morate izogibati v svoji kodi.

• Nasprotje tesne povezave je ohlapna povezava in vaša koda velja za dobro, če ima ohlapno povezane razrede.
• Ohlapno povezani razredi minimizirajo spremembe v vaši kodi, pomagajo narediti kodo večkratno uporabnejšo, vzdržljivejšo, prilagodljivejšo in stabilnejšo. Zdaj pa razpravljajmo enega za drugim o teh načelih ...

1. Načelo enotne odgovornosti

To načelo pravi, da Razred mora imeti samo en razlog za spremembo kar pomeni, da mora imeti vsak razred eno samo odgovornost ali eno nalogo ali en namen. Z drugimi besedami, razred mora imeti samo eno nalogo ali namen znotraj programskega sistema.

štetje različnih sql

Razumejmo načelo enotne odgovornosti na primeru:

Predstavljajte si peka, ki je odgovoren za peko kruha. Vloga peka je, da se osredotoči na nalogo peke kruha in poskrbi, da je kruh visoke kakovosti, pravilno pečen in v skladu s standardi pekarne.

• Če pa je pek odgovoren tudi za vodenje zalog, naročanje zalog, postrežbo strank in čiščenje pekarne, bi to kršilo SRP.
• Vsaka od teh nalog predstavlja ločeno odgovornost, z združevanjem pa bi lahko bila ogrožena pekova osredotočenost in učinkovitost pri peki kruha.
• Za upoštevanje SRP bi lahko pekarna dodelila različne vloge različnim posameznikom ali ekipam. Na primer, obstaja lahko ločena oseba ali ekipa, odgovorna za upravljanje inventarja, druga za naročanje zalog, druga za strežbo strankam in tretja za čiščenje pekarne.

2. Odprto/zaprto načelo

To načelo pravi, da Entitete programske opreme (razredi, moduli, funkcije itd.) morajo biti odprte za razširitev, vendar zaprte za spreminjanje kar pomeni, da bi morali imeti možnost razširiti vedenje razreda, ne da bi ga spreminjali.

Razumejmo odprto/zaprto načelo na primeru:

Predstavljajte si, da imate razred, imenovanPaymentProcessor>ki obdeluje plačila za spletno trgovino. Sprva jePaymentProcessor>razred podpira samo obdelavo plačil s kreditnimi karticami. Vendar pa želite razširiti njegovo funkcionalnost, da bo podpirala tudi obdelavo plačil s PayPal.

Namesto spreminjanja obstoječegaPaymentProcessor>Če želite dodati podporo za PayPal, lahko ustvarite nov razred, imenovanPayPalPaymentProcessor>ki podaljšujePaymentProcessor>razred. Na ta način,PaymentProcessor>razred ostaja zaprt za spreminjanje, vendar odprt za razširitev, pri čemer se drži načela odprto-zaprto

v polni obliki

3. Liskovljev princip zamenjave

Princip je uvedla Barbara Liskov leta 1987 in po tem principu Izpeljani ali podrejeni razredi morajo biti nadomestljivi za svoje osnovne ali nadrejene razrede . To načelo zagotavlja, da mora biti vsak razred, ki je podrejeni nadrejenemu razredu, uporaben namesto svojega nadrejenega brez nepričakovanega vedenja.

niz predmetov java

Razumejmo Liskovljev princip zamenjave na primeru:

Eden od klasičnih primerov tega načela je pravokotnik s štirimi stranicami. Višina pravokotnika je lahko poljubna vrednost, širina pa poljubna vrednost. Kvadrat je pravokotnik z enako širino in višino. Tako lahko rečemo, da lahko razširimo lastnosti razreda pravokotnika v razred kvadrata.

Če želite to narediti, morate podrejeni razred (kvadrat) zamenjati z nadrejenim razredom (pravokotnik), da bo ustrezal definiciji kvadrata s štirimi enakimi stranicami, vendar izpeljani razred ne vpliva na obnašanje nadrejenega razreda, tako da, če boste to storili da bo kršil Liskovovo substitucijsko načelo.

4. Načelo ločevanja vmesnika

To načelo je prvo načelo, ki velja za vmesnike namesto za razrede v SOLID-u in je podobno načelu ene same odgovornosti. Navaja, da ne silite nobenega odjemalca, da implementira vmesnik, ki zanj ni pomemben . Tu je vaš glavni cilj, da se osredotočite na izogibanje mastnemu vmesniku in dajete prednost številnim majhnim vmesnikom, specifičnim za odjemalce. Raje bi morali imeti več vmesnikov odjemalcev kot enega splošnega vmesnika in vsak vmesnik bi moral imeti posebno odgovornost.

Razumejmo načelo ločevanja vmesnika na primeru:

kako izbrati stolpce iz različnih tabel v sql

Recimo, da vstopite v restavracijo in ste čisti vegetarijanec. Natakar v tej restavraciji vam je dal menijsko kartico, ki vključuje vegetarijanske in nevegetarijanske izdelke, pijačo in sladkarije.

• V tem primeru bi morali kot stranka imeti menijsko kartico, ki vključuje samo vegetarijanske izdelke, ne pa vsega, česar ne jeste v svoji hrani. Tukaj mora biti jedilnik različen za različne vrste strank.
• Karto skupnega ali splošnega menija za vse lahko razdelite na več kartic namesto na eno. Uporaba tega principa pomaga zmanjšati stranske učinke in pogostost potrebnih sprememb.

5. Načelo inverzije odvisnosti

Načelo inverzije odvisnosti (DIP) je načelo v objektno usmerjenem načrtovanju, ki navaja to Moduli na visoki ravni ne bi smeli biti odvisni od modulov na nizki ravni. Oboje bi moralo biti odvisno od abstrakcij . Poleg tega abstrakcije ne smejo biti odvisne od podrobnosti. Podrobnosti naj bodo odvisne od abstrakcij.

• Preprosteje povedano, DIP predlaga, da bi se morali razredi zanašati na abstrakcije (npr. vmesnike ali abstraktne razrede) in ne na konkretne izvedbe.
• To omogoča bolj prilagodljivo in ločeno kodo, kar olajša spreminjanje implementacij brez vpliva na druge dele kodne baze.

Razumejmo načelo inverzije odvisnosti na primeru:

V ekipi za razvoj programske opreme so razvijalci odvisni od abstraktnega sistema za nadzor različic (npr. Git) za upravljanje in sledenje spremembam kodne baze. Niso odvisni od posebnih podrobnosti internega delovanja Gita.

To omogoča razvijalcem, da se osredotočijo na pisanje kode, ne da bi morali razumeti zapletenost izvajanja nadzora različic.