SOLID hverjar eru 5 meginreglur hlutbundinnar forritunar

SOLID er skammstöfun og vísar til fimm meginreglna hlutbundinnar hönnunar (OOD eða OOP). Þetta eru leiðbeiningar sem verktaki getur notað til að búa til hugbúnað sem auðvelt er að stjórna, viðhalda og lengja. Að skilja þessi hugtök mun gera þig að betri verktaki og hjálpa þér að forðast vandamál með stjórnun hugbúnaðar. Hvað þýðir það að vera góður forritari?

Allir sem hafa einhverja reynslu af forritun hugbúnaðar dæma hugbúnaðarkóða sem aðrir skrifa og nota dómstærðir byggðar á starfsferli sínum.

Í gegnum starfsferil minn hef ég þekkt marga forritara og ég hef séð þúsundir kóðalína og þegar ég þarf að leggja mat á færni verktaki lít ég aðallega á tvo þætti:

• Einfaldleiki við að lesa kóðann;
• Hversu líklegt er að kóði þeirra virki og þróist með tímanum.

Sem betur fer eru nokkur grundvallaratriði eða meginreglur sem gera það auðvelt að vera betri í kóðun.

skammstöfunin SOLID stendur fyrir:
S: meginregla um eina ábyrgð
O: opið-lokað meginregla
L: Skiptingarregla Liskov
I: Meginregla aðgreiningar viðmóta
D: Meginregla umbreytinga á ósjálfstæði

Byrjum á því að fara ofan í fyrstu SOLID meginregluna, þ.e.

Meginregla um eina ábyrgð

Bekkur (eða eining) ætti að hafa aðeins eina ástæðu til að breyta, til að þróast.

Hugmyndin sjálf er mjög einföld en til að ná þessum einfaldleika getur framkvæmdaleiðin verið mjög flókin. Bekkur ætti aðeins að hafa eina ástæðu til að breyta.

En afhverju? 

Af hverju er svo mikilvægt að hafa aðeins eina ástæðu til að breyta?

Til dæmis, ef það eru tvær mismunandi ástæður fyrir breytingum, má hugsa sér að tvö mismunandi teymi gætu unnið á sama kóðanum af tveimur mismunandi ástæðum. Hver og einn verður að innleiða sína eigin lausn, sem þegar um er að ræða samansett tungumál (eins og C ++, C # eða Java), gæti leitt til eininga sem eru ósamrýmanleg öðrum liðum eða öðrum hlutum forritsins.

Annað dæmi, ef þú notar túlkað tungumál, gætirðu þurft að prófa sama bekk eða einingu af mismunandi ástæðum. Þetta þýðir meiri vinnu, tíma og fyrirhöfn við gæðaeftirlit.

Að bera kennsl á eina eiginleikann sem bekkur eða eining ætti að hafa er miklu flóknara en að skoða gátlista til að keyra próf. 

En við skulum reyna að hugsa frá minna tæknilegu sjónarhorni, það er, við skulum reyna að greina notendur bekkjarins eða einingar okkar, það er hver mun nota það. Grundvallarþáttur sem við verðum alltaf að hafa í huga, er sú staðreynd að notendur forritsins eða kerfisins sem við þróum með þjónustu við tiltekna einingu munu vera þeir sem óska ​​eftir breytingum á því. Þeir sem þjóna munu biðja um að breyta bekknum eða einingunni. 

Nokkur dæmi um einingar og notkun þeirra:

• Viðhalds mát: notandinn samanstendur af gagnagrunninum stjórnendum og hugbúnaðararkitektum.
• Skýrslueining: notandinn samanstendur af skrifstofufólki, endurskoðendum og framleiðslu.
• Greiningarútreikningseining fyrir launastjórnunarkerfi: notendur geta verið lögfræðingar, stjórnendur og endurskoðendur.
• Textaleitareining fyrir bókasafnsstjórnunarkerfi: notandi getur verið fulltrúi bókasafnsins eða gestir og viðskiptavinir bókasafnsins sjálfs.

Svo ef fyrsta skrefið er að leita að leikurunum eða leikaranum sem hefur hlutverk viðmælanda við eininguna, getur það verið erfitt að tengja einstaklinga við öll hlutverkin. Í litlu fyrirtæki getur einn einstaklingur gegnt mörgum hlutverkum en í stóru fyrirtæki geta verið margir sem hafa eitt hlutverk. 

Það virðist eðlilegra að bera kennsl á hlutverk, frekar en fólk eða notendur.

Þess vegna:

• notandi hugbúnaðarkerfisins skilgreinir ástæður fyrir breytingunni;
• ábyrgð er fjölskylda aðgerða sem fullnægir þörfum tiltekins aðila, það er notanda kerfisins;
• leikararnir, notandinn verður uppspretta breytinga fyrir fjölskyldu virkni sem verður að fullnægja þörf notandans;
• þróun notendaþarfa, stýrir þróun virkni;

Við skulum sjá nokkur dæmi

Segjum sem svo að við séum með bókaflokk sem hylur hugtakið bók og virkni hennar.

bekk Bók {

    virka getTitle () {

        skila „A Great Book“;

    }

    virka getAuthor () {

        skila „Alessandro Baricco“;

    }

    virka næsta síðu () {

        // næsta síða

    }

    virka printCurrentPage () {

        bergmál „innihald núverandi síðu“;

    }

}

Þetta er mjög eðlilegur flokkur. Við erum með bók og bekkurinn getur gefið okkur titilinn, þeir geta gefið okkur höfundinn og þeir geta haldið áfram. Að lokum er það einnig fær um að prenta núverandi síðu á skjánum. 

Hins vegar er lítið vandamál. 

Ertu að hugsa um leikarana sem taka þátt í stjórnun bókarinnar, hverjir gætu þeir verið? 

Við getum auðveldlega hugsað um tvo mismunandi leikara hér: Bókastjórnun (eins og bókavörður) Og Kerfi gagnaskila (eins og hvernig við viljum koma efni til notandans: á skjánum, myndrænt notendaviðmót, aðeins texta notendaviðmót, kannski prentun). 

Við höfum því tvo mjög ólíka leikara sem hafa samskipti við bekkinn.

Í hnotskurn gerir þessi flokkur blöndu á milli:

• viðskiptarökfræði með 
• kynninguna 

þetta getur verið vandamál vegna þess að það brýtur gegn meginábyrgðarreglunni (SRP). 

Hvernig getum við breytt, hvernig getum við bætt þessa kóða til að virða meginregluna um eina ábyrgð?

Skoðaðu eftirfarandi kóða:

bekk Bók {

    virka getTitle () {

        skila „Oceano Mare“;

    }

    virka getAuthor () {

        skila „Alessandro Baricco“;

    }

    virka blaðsíða () {

        // næsta síða

    }

    virka getCurrentPage () {

        bergmál „innihald núverandi síðu“;

    }

}

tengiprentari {

    virka printPage ($ blaðsíða);

}

class StampaLibro útfærir prentara {

    virka prentSíður ($ blaðsíða) {

        bergmál $ síðu;

    }

}

bekk HtmlPrinter útfærir prentara {

    virka prentSíður ($ blaðsíða) {

        bergmál ' '. $ síðu. ' ';

    }

}

Þetta mjög einfalda dæmi sýnir hvernig á að aðgreina framsetningu frá viðskiptarökfræði og í samræmi við SRP býður það upp á mikla kosti í sveigjanleika verkefnisins.

Lítum á annað dæmi:

Dæmi svipað og hér að ofan er þegar hlutur getur vistað og sótt sig frá kynningunni.

bekk Bók {

    virka getTitle () {

        skila „Oceano Mare“;

    }

    virka getAuthor () {

        skila „Alessandro Baricco“;

    }

    virka blaðsíða () {

        // næsta síða

    }

    virka getCurrentPage () {

        skila „innihaldi núverandi síðu“;

    }

    virka vista () {

        $ filename = '/ skjöl /'. $ þetta-> getTitolo (). '-'. $ þetta-> getAuthor ();

        file_put_contents ($ filename, serialize ($ this));

    }

}

Eins og áður getum við líka borið kennsl á mismunandi leikara eins og áður Bókastjórnun (eins og bókavörður) Og Þrautseigju. Hvenær sem við viljum breyta leiðinni frá síðu til blaðs, verðum við að breyta þessum flokki. Við getum haft nokkrar ástæður fyrir breytingum.

bekk Bók {

    virka getTitle () {

        skila „Oceano Mare“;

    }

    virka getAuthor () {

        skila „Alessandro Baricco“;

    }

    virka blaðsíða () {

        // næsta síða

    }

    virka getCurrentPage () {

        skila „innihaldi núverandi síðu“;

    }

}

flokkur SimpleFilePersistence {

    virka vista (Bóka $ bók) {

        $ filename = '/ skjöl /'. $ book-> getTitle (). '-'. $ book-> getAuthor ();

        file_put_contents ($ filename, serialize ($ book));

    }

}

Að færa þrautseigjuna yfir í annan flokk mun greinilega skilja á milli ábyrgðarinnar og við erum frjáls til að skiptast á þrautseigju án þess að hafa áhrif á bókaflokkinn okkar. Til dæmis, að innleiða DatabasePersistence bekk væri léttvægt og viðskiptarökfræði okkar byggð í kringum bókastarfsemi mun ekki breytast.

Haltu áfram að lesa seinni meginregluna Opið / lokað ->