Oft hitti ég forritara sem hafa ekki heyrt um SOLID meginreglurnar (við . — Þýðing) eða hlutbundin forritun (OOP), eða hafa heyrt um þær, en ekki nota þær í reynd. Þessi grein lýsir ávinningi OOP reglna sem hjálpa verktaki í daglegu starfi. Sum þeirra eru vel þekkt, önnur ekki svo mikið, svo greinin mun nýtast bæði byrjendum og reynda forritara.
Við minnum á: fyrir alla Habr lesendur - 10 rúblur afsláttur þegar þú skráir þig á hvaða Skillbox námskeið sem er með því að nota Habr kynningarkóðann.
Skillbox mælir með: Fræðslunámskeið á netinu .
ÞURR (ekki endurtaka sjálfan þig)
Nokkuð einföld meginregla, kjarni hennar er skýr af nafninu: "Ekki endurtaka þig." Fyrir forritara þýðir þetta þörfina á að forðast tvítekinn kóða, sem og tækifæri til að nota abstrakt í vinnu sinni.
Ef það eru tveir endurteknir hlutar í kóðanum ætti að sameina þá í eina aðferð. Ef harðkóðað gildi er notað oftar en einu sinni er þess virði að breyta því í opinberan fasta.
Þetta er nauðsynlegt til að einfalda kóðann og auðvelda viðhald hans, sem er meginmarkmið OOP. Þú ættir heldur ekki að ofnota sambandið, þar sem sami kóði mun ekki standast staðfestingu með bæði OrderId og SSN.
Encapsulating Breytingar
Hugbúnaðarvörur flestra fyrirtækja eru í stöðugri þróun. Þetta þýðir að það þarf að gera breytingar á kóðanum, það þarf að styðja hann. Þú getur gert líf þitt auðveldara með því að nota hjúpun. Þetta gerir þér kleift að prófa og viðhalda núverandi kóðagrunni á skilvirkari hátt. .
Ef þú skrifar á Java, þá .
Opin/lokuð regla
Auðvelt er að muna þessa meginreglu með því að lesa eftirfarandi yfirlýsingu: "Hugbúnaðareiningar (flokkar, einingar, aðgerðir osfrv.) ættu að vera opnar fyrir framlengingu, en lokaðar fyrir breytingar." Í reynd þýðir þetta að þeir geta leyft að breyta hegðun sinni án þess að breyta frumkóðanum.
Meginreglan er mikilvæg þegar breytingar á frumkóðanum krefjast endurskoðunar kóða, einingaprófunar og annarra aðferða. Kóði sem fylgir opnu/lokuðu reglunni breytist ekki þegar hann er framlengdur, þannig að það eru mun færri vandamál með hann.
Hér er dæmi um kóða sem brýtur gegn þessari meginreglu.
Ef þú þarft að breyta einhverju í því mun það taka mikinn tíma þar sem breyta þarf öllum köflum kóðans sem tengjast viðkomandi broti.
Við the vegur, hreinskilni-lokun er ein af meginreglum SOLID.
Ein ábyrgðarregla (SRP)
Önnur meginregla úr SOLID settinu. Þar segir að „það er aðeins ein orsök sem veldur breytingu á stétt“. Bekkurinn leysir aðeins eitt vandamál. Það kann að hafa nokkrar aðferðir, en hver þeirra er aðeins notuð til að leysa sameiginlegt vandamál. Allar aðferðir og eiginleikar ættu aðeins að þjóna þessu.
Gildi þessarar meginreglu er að hún losar um tenginguna milli einstakra hugbúnaðarhluta og kóðans. Ef þú bætir fleiri en einni virkni við flokk kynnir það tengsl milli aðgerðanna tveggja. Þannig að ef þú breytir einum þeirra eru miklar líkur á að eyðileggja þann seinni, sem er tengdur þeirri fyrri. Og þetta þýðir að auka prófunarlotur til að bera kennsl á öll vandamál fyrirfram.
Dependency Inversion Principle (DIP)
Hér að ofan er kóðadæmi þar sem AppManager er háð EventLogWriter, sem aftur er nátengt AppManager. Ef þú þarft aðra leið til að sýna tilkynningu, hvort sem það er ýtt, SMS eða tölvupóstur, þarftu að breyta AppManager flokki.
Vandamálið er hægt að leysa með DIP. Svo, í stað AppManager, biðjum við um EventLogWriter, sem verður slegið inn með því að nota rammann.
DIP gerir það auðvelt að skipta út einstökum einingum fyrir aðrar með því að breyta ósjálfstæðiseiningunni. Þetta gerir það mögulegt að breyta einni einingu án þess að hafa áhrif á hinar.
Samsetning í stað arfs
Það eru tvær meginleiðir til að endurnýta kóða: arfleifð og samsetning, sem báðar hafa sína kosti og galla. Venjulega er annað valið vegna þess að það er sveigjanlegra.
Samsetning gefur þér möguleika á að breyta hegðun bekkjar á keyrslutíma með því að stilla eiginleika hans. Við útfærslu viðmóta er notast við fjölbreytni sem gefur sveigjanlegri útfærslu.
Even Effective Java eftir Joshua Bloch ráðleggur að velja samsetningu fram yfir erfðir.
Barbara Liskov skiptireglan (LSP)
Önnur meginregla úr SOLID verkfærakistunni. Þar kemur fram að undirgerðir verði að vera staðgengilegar fyrir yfirgerðina. Það er að segja að aðferðir og aðgerðir sem vinna með ofurflokki ættu að geta virkað án vandræða með undirflokka hans.
LSP tengist bæði meginreglunni um eina ábyrgð og meginregluna um sameiginlega ábyrgð. Ef flokkur veitir meiri virkni en undirflokkur, þá mun sá síðarnefndi ekki styðja hluta af virkninni, sem brýtur gegn þessari meginreglu.
Hér er stykki af kóða sem stangast á við LSP.
Flatarmál (Rehyrningur r) aðferðin reiknar út flatarmál rétthyrnings. Forritið mun hrynja eftir að Square hefur verið keyrt vegna þess að Square er ekki rétthyrningur hér. Samkvæmt LSP meginreglunni ættu aðgerðir sem nota tilvísanir í grunnflokka að geta notað hluti af afleiddum flokkum án viðbótarleiðbeininga.
Þessi meginregla, sem er sérstök skilgreining á undirtegund, var lögð fram af Barbara Liskov í aðaltónlist ráðstefnu árið 1987 sem ber yfirskriftina „Data Abstraction and Hierarchy“, þess vegna heitir hún.
Viðmótsaðskilnaðarreglan (ISP)
Önnur SOLID meginregla. Samkvæmt henni á ekki að útfæra viðmót sem ekki er notað. Að fylgja þessari meginreglu hjálpar kerfinu að vera sveigjanlegt og hentugur til endurstillingar þegar breytingar eru gerðar á rekstrarrökfræðinni.
Oftast gerist þetta þegar viðmótið inniheldur nokkrar aðgerðir í einu og viðskiptavinurinn þarf aðeins eina þeirra.
Þar sem að skrifa viðmót er erfitt verkefni, mun það vera áskorun að breyta því eftir að verkinu er lokið án þess að brjóta neitt.
Kosturinn við ISP meginregluna í Java er að allar aðferðir verða að vera innleiddar fyrst, og aðeins þá er hægt að nota þær af flokkum. Þess vegna gerir meginreglan það mögulegt að fækka aðferðum.
Forritun fyrir viðmótið, ekki útfærsluna
Allt hér er ljóst af titlinum. Að beita þessari meginreglu leiðir til þess að búið er til sveigjanlegan kóða sem getur unnið með hvaða nýrri útfærslu viðmótsins sem er.
Þú ættir að nota viðmótsgerðina fyrir breytur, skilagerðir eða aðferðarröksemdategundina. Dæmi er að nota SuperClass frekar en SubClass.
Það er:
Listitölur= getNumbers();
En ekki:
ArrayList numbers = getNumbers();
Hér er hagnýt útfærsla á því sem fjallað er um hér að ofan.
Umboðsregla
Algengt dæmi eru equals() og hashCode() aðferðirnar í Java. Þegar nauðsynlegt er að bera saman tvo hluti er þessari aðgerð úthlutað til samsvarandi flokks í stað viðskiptavinarins.
Kosturinn við regluna er að það er engin tvítekning á kóða og það er tiltölulega einfalt að breyta hegðun. Það á einnig við um sendinefnd viðburða.
Allar þessar reglur gera þér kleift að skrifa sveigjanlegri, fallegri og áreiðanlegri kóða með mikilli samheldni og lítilli tengingu. Auðvitað eru kenningar góðar, en til þess að þróunaraðili geti raunverulega notfært sér þá þekkingu sem aflað er, þarf æfingu. Þegar þú hefur náð góðum tökum á OOP meginreglum gæti næsta skref þitt verið að læra hönnunarmynstur til að leysa algeng hugbúnaðarþróunarvandamál.
Skillbox mælir með:
- Verklegt námskeið .
- Notað netnámskeið .
- Tveggja ára verklegt nám .
Heimild: www.habr.com