Askotan SOLID-en printzipioei buruz entzun ez duten garatzaileek (gu . - Transl.) edo objektuetara zuzendutako programazioa (OOP), edo entzuna, baina ez erabili praktikan. Artikulu honek garatzaileari eguneroko lanean laguntzen dioten OOP printzipioen onurak deskribatzen ditu. Horietako batzuk ezagunak dira, beste batzuk ez horrenbeste, beraz, artikulua erabilgarria izango da bai hasiberrientzat, bai dagoeneko esperientziadun programatzaileentzat.
Gogoratzen dugu: "Habr" irakurle guztientzat - 10 errubloko deskontua "Habr" promozio-kodea erabiliz Skillbox-eko edozein ikastarotan izena ematean.
Skillbox-ek gomendatzen du: Hezkuntza online ikastaroa .
LEHORRAK (Ez errepikatu)
Printzipio nahiko sinplea, zeinaren funtsa izenetik argi dago: "Ez errepikatu". Programatzaile batentzat, horrek kode bikoiztuak saihestu beharra esan nahi du, baita abstrakzioa lanean erabiltzeko gaitasuna ere.
Kodean bi atal errepikatzen badira, metodo batean konbinatu beharko lirateke. Kode gogorreko balio bat behin baino gehiagotan erabiltzen bada, merezi du konstante publiko bihurtzea.
Hau beharrezkoa da kodea sinplifikatzeko eta mantentzea errazteko, hori baita OOPren zeregin nagusia. Sindikatua ere ez duzu abusatu behar, kode berak ez baitu egiaztapena gaindituko OrderId zein SSNrekin.
Aldatu enkapsulazioa
Enpresa gehienen software produktuak etengabe garatzen ari dira. Horrek esan nahi du kodea aldatu behar dela, mantendu egin behar dela. Enkapsulazioarekin zure bizitza erraztu dezakezu. Honek lehendik dagoen kode-oinarria modu eraginkorragoan probatu eta mantentzeko aukera emango dizu. .
Javan idazten ari bazara .
Irekitasun / hurbiltasunaren printzipioa
Printzipio hori erraz gogoratu daiteke adierazpen hau irakurrita: "Software-entitateak (klaseak, moduluak, funtzioak, etab.) zabalik egon behar dute zabaltzeko, baina itxita aldatzeko". Praktikan, horrek esan nahi du iturburu-kodea aldatu gabe beren portaera aldatzeko baimena eman dezaketela.
Printzipioa garrantzitsua da iturburu-kodearen aldaketek berrikuspenak, unitate-probak eta beste prozedura batzuk behar dituztenean. Ireki/itxi printzipioari men egiten dion kodea ez da aldatzen luzatzen denean, beraz, askoz arazo gutxiago daude.
Hona hemen printzipio hori urratzen duen kodearen adibide bat.
Bertan zerbait aldatu behar baduzu, denbora asko beharko da, nahi duzun zatiarekin lotura duten kodearen zati guztiak aldatu beharko dituzulako.
Bide batez, irekitasuna-itxitasuna SOLID-en printzipioetako bat da.
Erantzukizun bakarraren printzipioa (SRP)
SOLID multzoko beste printzipio bat. Bertan dio "klase aldaketa bat ekartzen duen arrazoi bakarra dagoela". Klaseak zeregin bakarra du. Hainbat metodo izan ditzake, baina horietako bakoitza arazo arrunt bat konpontzeko bakarrik erabiltzen da. Metodo eta propietate guztiek hori bakarrik balio behar dute.
Printzipio honen balioa software-pieza bakar baten eta kodearen arteko lotura askatzen duela da. Klase bati funtzionaltasun bat baino gehiago gehitzeak bi funtzioen arteko erlazioa sartzen du. Horrela, horietako bat aldatuz gero, aukera handia dago bigarrena hondatzeko, lehenengoari dagokiona. Eta horrek proba-zikloak areagotzea esan nahi du, arazo guztiak aldez aurretik identifikatzeko.
Mendekotasun Inbertsioaren Printzipioa (DIP)
Goiko kode-adibide bat da, non AppManager-a EventLogWriter-en araberakoa den, eta, aldi berean, AppManager-ekin oso lotuta dagoen. Jakinarazpena erakusteko beste modu bat behar baduzu, push, SMS edo posta elektronikoa izan, AppManager klasea aldatu behar duzu.
Arazoa DIP-rekin konpondu daiteke. Beraz, AppManager-en ordez, EventLogWriter bat eskatzen dugu, markoa erabiliz injektatuko dena.
DIP-ek modulu indibidualak beste batzuekin erraz ordezkatzea ahalbidetzen du, mendekotasun modulua aldatuz. Honek modulu bat aldatzea ahalbidetzen du besteei eragin gabe.
Konposizioa herentziaren ordez
Kodea berrerabiltzeko bi modu nagusiak herentzia eta konposizioa dira, bakoitzak bere abantailak eta desabantailak dituena. Bigarrena hobetsi ohi da, malguagoa delako.
Konposizioak exekuzio garaian klase baten portaera aldatzeko gaitasuna ematen dizu bere propietateak ezarriz. Interfazeak ezartzerakoan, polimorfismoa erabiltzen da, eta horrek inplementazio malguagoa ematen du.
Nahiz eta "Java eraginkorra" Joshua Blochek konposizioaren alde egitea gomendatzen du herentziaren aldean.
Barbara Liskov ordezkapen printzipioa (LSP)
SOLID tresnaren beste printzipio bat. Azpimotak supertipo baterako ordezkagarriak izan behar direla dio. Hau da, superklase batekin lan egiten duten metodo eta funtzioek bere azpiklaseekin arazorik gabe funtzionatzeko gai izan behar dute.
LSP Erantzukizun Bakararen Printzipioarekin eta Erantzukizunen Banaketaren Printzipioarekin lotuta dago. Klase batek azpiklase batek baino funtzionalitate gehiago ematen badu, azken honek ez du funtzionalitateren bat onartuko, printzipio hau urratuz.
Hona hemen LSP kontraesanean dagoen kode zati bat.
Area (Laukizuzena r) metodoak Laukizuzen baten azalera kalkulatzen du. Programak huts egingo du Square exekutatu ondoren, Square ez baita hemen Laukizuzena. LSP printzipioaren arabera, oinarrizko klaseetarako erreferentziak erabiltzen dituzten funtzioek klase deribatuetako objektuak instrukzio gehigarririk gabe erabiltzeko gai izan behar dute.
Printzipio hau, azpimota baten definizio espezifikoa dena, Barbara Liskov-ek proposatu zuen 1987an "Datuen abstrakzioa eta hierarkia" izeneko hitzaldian -hortik datorkio izena-.
Interfazea bereizteko printzipioa (ISP)
Beste printzipio SOLIDO bat. Haren ustez, erabiltzen ez den interfaze bat ez da inplementatu behar. Printzipio horri jarraitzeak sistema malgu eta birfaktorizagarria izaten laguntzen du lan-logikan aldaketak egiterakoan.
Gehienetan, egoera hau gertatzen da interfazeak aldi berean hainbat funtzionalitate dituenean eta bezeroak horietako bakarra behar duenean.
Interfaze bat idaztea lan konplexua denez, lana amaitu ondoren, ezer hautsi gabe aldatzea arazo bat izango da.
Javan ISP printzipioaren abantaila da metodo guztiak inplementatu behar direla lehenik, eta orduan bakarrik klaseek erabil ditzakete. Hori dela eta, printzipioak metodo kopurua murriztea ahalbidetzen du.
Interfaze baterako programatzea, ez inplementazio bat
Hemen dena argi dago izenetik. Printzipio hau aplikatzeak edozein interfaze inplementazio berrirekin funtziona dezakeen kode malgua dakar.
Interfaze mota bat erabili behar duzu aldagaietarako, itzulera motetarako edo metodoaren argumentu motarako. Adibide bat SuperClass erabiltzea da SubClass baino.
Hori da:
Zerrenda zenbakiak= getNumbers();
Baina ez:
ArrayList zenbakiak = getNumbers();
Hona hemen goian esandakoaren ezarpen praktikoa.
Ordezkaritza printzipioa
Adibide arrunt bat equals() eta hashCode() metodoak dira Javan. Bi objektu konparatu behar direnean, ekintza hau klase egokiari delegatzen zaio bezeroaren klaseari ordez.
Printzipioaren abantaila da ez dagoela kodea bikoizketarik eta nahiko erraza dela portaera aldatzea. Ekitaldien delegazioari ere aplikatzen zaio.
Printzipio hauek guztiek kohesio handiko eta akoplamendu baxuko kode malguagoa, eder eta fidagarriagoa idazteko aukera ematen dute. Noski, teoria ona da, baina garatzaile batek lortutako ezagutza benetan erabiltzen hasteko, praktika behar da. OOP-aren printzipioak menderatu ondoren hurrengo urratsa softwarearen garapen-arazo arruntak konpontzeko diseinu-ereduen azterketa izan daiteke.
Skillbox-ek gomendatzen du:
- Ikastaro praktikoa .
- Lineako ikastaroa aplikatua .
- Bi urteko ikastaro praktikoa .
Iturria: www.habr.com