SOLID beth yw 5 egwyddor rhaglennu gwrthrychau-ganolog

Ffigurau geometrig solet solet
Hyfforddiant
1

Acronym yw SOLID, sy'n cyfeirio at bum egwyddor dylunio gwrthrych-ganolog (OOD neu OOP). Canllawiau yw'r rhain y gall datblygwyr eu defnyddio i greu meddalwedd sy'n hawdd ei reoli, ei chynnal a'i hymestyn. Bydd deall y cysyniadau hyn yn eich gwneud chi'n well datblygwr ac yn eich helpu i osgoi problemau rheoli meddalwedd. Beth mae'n ei olygu i fod yn rhaglennydd da?

Mae unrhyw un sydd â rhywfaint o brofiad mewn rhaglennu meddalwedd yn barnu cod meddalwedd a ysgrifennwyd gan eraill, gan ddefnyddio paramedrau barn yn seiliedig ar eu llwybr gyrfa.

Yn ystod fy ngyrfa broffesiynol, rwyf wedi adnabod llawer o ddatblygwyr, ac rwyf wedi gweld miloedd o linellau cod a phan fydd angen i mi asesu sgil datblygwr, rwy'n edrych ar ddau ffactor yn bennaf:

  • Symlrwydd wrth ddarllen y cod;
  • Pa mor debygol yw eu cod i weithio ac esblygu dros amser.

Yn ffodus, mae yna rai hanfodion neu egwyddorion sy'n ei gwneud hi'n hawdd bod yn well wrth godio.

mae'r acronym SOLID yn sefyll am:
S: egwyddor cyfrifoldeb sengl
O: egwyddor caeedig agored
L: Egwyddor amnewid Liskov
I: Egwyddor gwahanu rhyngwyneb
D: Egwyddor Gwrthdroi Dibyniaethau

Dechreuwn trwy ymchwilio i'r egwyddor SOLID gyntaf, sef y

Egwyddor Cyfrifoldeb Sengl

Dylai dosbarth (neu fodiwl) fod ag un rheswm yn unig i newid, i esblygu.

Mae'r cysyniad ei hun yn syml iawn, ond er mwyn cyflawni'r symlrwydd hwn gall y llwybr gweithredu fod yn gymhleth iawn. Dim ond un rheswm ddylai dosbarth fod â newid.

Ond pam? 

Pam ei bod mor bwysig cael dim ond un rheswm i newid?

Er enghraifft, os oes dau reswm gwahanol dros newid, mae'n bosibl y gallai dau dîm gwahanol weithio ar yr un cod am ddau reswm gwahanol. Bydd yn rhaid i bob un weithredu ei ddatrysiad ei hun, a allai, yn achos iaith wedi'i llunio (fel C ++, C # neu Java), arwain at fodiwlau sy'n anghydnaws â thimau eraill neu rannau eraill o'r cais.

Enghraifft arall, os ydych chi'n defnyddio iaith wedi'i dehongli, efallai y bydd yn rhaid i chi ailbrofi'r un dosbarth neu fodiwl am wahanol resymau. Mae hyn yn golygu mwy o waith, amser ac ymdrech i reoli ansawdd.

Mae nodi'r un nodwedd y dylai dosbarth neu fodiwl ei chael yn llawer mwy cymhleth nag edrych ar restr wirio i gynnal profion yn unig. 

Ond gadewch i ni geisio meddwl o safbwynt llai technegol, hynny yw, gadewch i ni geisio dadansoddi defnyddiwr ein dosbarth neu ein modiwl, hynny yw pwy fydd yn ei ddefnyddio. Agwedd sylfaenol y mae'n rhaid i ni ei chadw mewn cof bob amser, yw'r ffaith mai defnyddwyr y cymhwysiad neu'r system a ddatblygwn sy'n cael eu gwasanaethu gan fodiwl penodol fydd y rhai sy'n gofyn am addasiadau iddo. Bydd y rhai a wasanaethir yn gofyn am newid y dosbarth neu'r modiwl. 

Rhai enghreifftiau o fodiwlau a'u defnydd:

  • Modiwl cynnal a chadw: mae'r defnyddiwr yn cynnwys gweinyddwyr cronfa ddata a phenseiri meddalwedd.
  • Modiwl adrodd: mae'r defnyddiwr yn cynnwys gweithwyr swyddfa, cyfrifwyr a chynhyrchu.
  • Modiwl cyfrifo taliadau ar gyfer system rheoli cyflogres: gall defnyddwyr gynnwys cyfreithwyr, rheolwyr a chyfrifwyr.
  • Modiwl chwilio testun ar gyfer system rheoli llyfrgell: gall y defnyddiwr gael ei gynrychioli gan y llyfrgellydd neu gan ymwelwyr a chwsmeriaid y llyfrgell ei hun.

Felly os mai'r cam cyntaf yw chwilio am yr actorion neu'r actor sydd â rôl rhyng-gysylltydd â'r modiwl, gall fod yn anodd cysylltu unigolion â'r holl rolau. Mewn cwmni bach, gall un person chwarae sawl rôl tra mewn cwmni mawr gall fod sawl person sydd ag un rôl. 

Mae'n ymddangos yn fwy rhesymol nodi rolau, yn hytrach na phobl neu ddefnyddwyr.

Felly:

  • mae defnyddiwr y system feddalwedd yn diffinio'r rhesymau dros y newid;
  • mae cyfrifoldeb yn deulu o swyddogaethau sy'n diwallu anghenion actor penodol, hynny yw, defnyddiwr y system;
  • yr actorion, daw'r defnyddiwr yn ffynhonnell newid i'r teulu o swyddogaethau sy'n gorfod diwallu angen y defnyddiwr;
  • esblygiad anghenion defnyddwyr, yn arwain esblygiad ymarferoldeb;

Egwyddorion SOLID

Gawn ni weld rhai enghreifftiau

Tybiwch fod gennym ni ddosbarth Llyfr sy'n crynhoi cysyniad llyfr a'i ymarferoldeb.

Llyfr dosbarth {

    swyddogaeth getTitle () {

        dychwelyd “Llyfr Gwych”;

    }

    swyddogaeth getAuthor () {

        dychwelyd “Alessandro Baricco”;

    }

    swyddogaeth nextpage () {

        // tudalen nesaf

    }

    swyddogaeth printCurrentPage () {

        adleisio “cynnwys y dudalen gyfredol”;

    }

}

Mae hwn yn ddosbarth arferol iawn. Mae gennym lyfr, a gall y dosbarth roi'r teitl inni, gallant roi'r awdur inni, a gallant symud ymlaen. Yn olaf, mae hefyd yn gallu argraffu'r dudalen gyfredol ar y sgrin. 

Fodd bynnag, mae problem fach. 

Wrth feddwl am yr actorion sy'n ymwneud â rheoli gwrthrych y Llyfr, pwy allen nhw fod? 

Gallwn yn hawdd feddwl am ddau actor gwahanol yma: Rheoli llyfrau (fel y llyfrgellydd) A Mecanwaith cyflwyno data (fel sut rydyn ni am gyflwyno cynnwys i'r defnyddiwr: ar-sgrin, rhyngwyneb defnyddiwr graffigol, rhyngwyneb defnyddiwr testun yn unig, argraffu efallai). 

Felly mae gennym ddau actor gwahanol iawn yn rhyngweithio â'r dosbarth.

Yn gryno mae'r dosbarth hwn yn gwneud cymysgedd rhwng:

  • rhesymeg busnes gyda 
  • y cyflwyniad 

gall hyn fod yn broblem oherwydd ei bod yn torri'r egwyddor atebolrwydd sengl (SRP). 

Sut allwn ni newid, sut allwn ni wella'r cod hwn i barchu egwyddor cyfrifoldeb sengl?

Cymerwch gip ar y cod canlynol:

Llyfr dosbarth {

    swyddogaeth getTitle () {

        dychwelyd “Oceano Mare”;

    }

    swyddogaeth getAuthor () {

        dychwelyd “Alessandro Baricco”;

    }

    tudalen troi swyddogaeth () {

        // tudalen nesaf

    }

    swyddogaeth getCurrentPage () {

        adleisio “cynnwys y dudalen gyfredol”;

    }

}

argraffydd rhyngwyneb {

    printPage swyddogaeth ($ tudalen);

}

dosbarth StampaLibro yn gweithredu Argraffydd {

    printPages swyddogaeth ($ tudalen) {

        adleisio $ tudalen;

    }

}

 

dosbarth HtmlPrinter yn gweithredu Argraffydd {

    printPages swyddogaeth ($ tudalen) {

        adleisio ' '. $ tudalen. '' ';

    }

}

Mae'r enghraifft syml iawn hon yn dangos sut i wahanu cyflwyniad oddi wrth resymeg busnes, ac yn unol â SRP mae'n cynnig manteision mawr yn hyblygrwydd ein prosiect.

Gadewch i ni edrych ar enghraifft arall:

Enghraifft debyg i'r un uchod yw pan all gwrthrych arbed ac adfer ei hun o'r cyflwyniad.

Llyfr dosbarth {

    swyddogaeth getTitle () {

        dychwelyd “Oceano Mare”;

    }

    swyddogaeth getAuthor () {

        dychwelyd “Alessandro Baricco”;

    }

    tudalen troi swyddogaeth () {

        // tudalen nesaf

    }

    swyddogaeth getCurrentPage () {

        dychwelyd "cynnwys y dudalen gyfredol";

    }

    swyddogaeth arbed () {

        $ filename = '/ documents /'. $ hwn-> getTitolo (). '-'. $ hwn-> getAuthor ();

        file_put_contents ($ enw ffeil, cyfresoli ($ hwn));

    }

}

Fel o'r blaen, yma hefyd gallwn adnabod gwahanol actorion fel Rheoli llyfrau (fel y llyfrgellydd) A Dyfalbarhad. Pryd bynnag rydyn ni am newid y ffordd rydyn ni'n mynd o dudalen i dudalen, mae angen i ni newid y dosbarth hwn. Gallwn fod â sawl rheswm dros newid.

Llyfr dosbarth {

    swyddogaeth getTitle () {

        dychwelyd “Oceano Mare”;

    }

    swyddogaeth getAuthor () {

        dychwelyd “Alessandro Baricco”;

    }

    tudalen troi swyddogaeth () {

        // tudalen nesaf

    }

    swyddogaeth getCurrentPage () {

        dychwelyd "cynnwys y dudalen gyfredol";

    }

}

dosbarth SimpleFilePersistence {

    arbed swyddogaeth (Llyfr $ llyfr) {

        $ filename = '/ documents /'. $ llyfr-> getTitle (). '-'. $ llyfr-> getAuthor ();

        file_put_contents ($ enw ffeil, cyfresoli ($ llyfr));

    }

}

Bydd symud y gweithrediad dyfalbarhad i ddosbarth arall yn amlwg yn gwahanu cyfrifoldebau a byddwn yn rhydd i gyfnewid dulliau dyfalbarhad heb effeithio ar ein dosbarth Llyfrau. Er enghraifft, byddai gweithredu dosbarth DatabasePersistence yn ddibwys, ac ni fydd ein rhesymeg busnes wedi'i adeiladu o amgylch gweithrediadau llyfrau yn newid.

Parhewch trwy ddarllen yr ail egwyddor Agored / Caeedig ->

Sylwebaeth 1

Gadewch sylw

Il Tuo e-bost indirizzo heb Sara pubblicato. Rwyf Campi sono obbligatori contrassegnati *

egwyddor liskov
Hyfforddiant
Egwyddor Amnewid Liskov, trydydd egwyddor SOLID

Ni ddylai dosbarthiadau plant byth effeithio na newid diffiniadau math y dosbarth rhieni. Cyflwynwyd cysyniad yr egwyddor hon gan Barbara Liskov mewn cyweirnod o gynhadledd 1987 ac yna ei gyhoeddi mewn erthygl ynghyd â Jannette Wing ym 1994. Eu diffiniad gwreiddiol…

tueddiadau marchnata google
Hyfforddiant
Sut i ddefnyddio Google Trends ar gyfer marchnata amser real

Un o'r anawsterau mawr a wynebodd cwmnïau yn 2020 oedd deall ym mha sectorau cynnyrch i arallgyfeirio eu busnes: mewn gwirionedd, mae'r rhan fwyaf o'r sectorau diwydiannol wedi dioddef ôl-effeithiau trwm gan ei gwneud yn amhosibl bron i gwmnïau eu treiddio, yn enwedig fel chwaraewr newydd. Ychydig iawn o sectorau gweithgynhyrchu ...

strategaeth deallusrwydd busnes
dulliau
Strategaethau ar gyfer Cudd-wybodaeth Busnes lwyddiannus

Mae adeiladu strategaeth lwyddiannus ar gyfer eich Deallusrwydd Busnes yn dechrau gyda gweledigaeth gywir o'r amcanion. Gwelwn isod rai pwyntiau sylfaenol. Asesu'r sefyllfa bresennol Byddai'n gamgymeriad difrifol i danamcangyfrif yr agwedd hon. Mae gwerthuso'r sefyllfa bresennol yn golygu dadansoddi prosesau, strwythurau ...