Disainimudelid algajatele

Kui olete juba kirjutanud programmid suurte/väikeste toodete või tarkvararakenduste jaoks, olete suure tõenäosusega kasutanud palju kujundusmustreid… kuigi on võimalik, et need ei pruugi olla üks enimkasutatud / standardseid kujundusmustreid.

Aga jah, kujundusmustri rakendamisel ja kujundusmustri “kasutamisel” on ilmne erinevus… mõlemal juhul saab disainimustritega töötav inimene sellest aru või saab sellest kergesti aru.

Asi on selles, et disainimustrid pole programmeerijatele uued.

Selles allolevas artiklis püüan selgitada disainimustreid nende põhitõdesid ja uurime erinevatest mustritest, näidetest jms ühest teisest artiklist.

Mis on kujundusmuster?

Alustada…

Arvan, et parim viis disainimustrite mõistmise alustamiseks on mõista mittetehnilisi mustreid, mida me teadlikult/teadmatult oma igapäevaelus järgime.

Näiteks võtame palju vaba töökoha jaoks esitatud CV-sid. Kõigi CV ei näe välja ühesugune… kuigi nad kõik kipuvad tegema sama asja, see tähendab lugejale, mida nad oskavad, või kuidas ta võiks sellele tööle sobida.

Enamik neist, kes esitavad CV töökohtadele, teavad, et nad peavad esitama CV koos konkreetse teabega vormindatud Wordi dokumendis.

See… on muster, mille kohaselt kõik esitavad CV, milles on väljendatud teatud kogum teavet.

Kui soovite… nimetage seda mallideks, mitte mustriteks. Kujundusmallid.

Päris elus on palju selliseid asju, mis on mustrid. Mõnele inimesele meeldivad järgmised näited:

Kõik kokad üle maailma küpsetavad pitsat või friikartuleid ühtemoodi. Kuigi nad võivad seda täiendada / maitsestada erinevalt. See on muster.

Iga auto disain järgib põhilist disainimustrit, nelja ratast, rooliratast, põhiajami süsteemi nagu gaasipedaal-katkestus-sidur jne.

Kõik korduvalt ehitatud/toodetud asjad järgivad oma disainis paratamatult mustrit… olgu selleks siis autod, pizza, pangaautomaadid, mis iganes… isegi hambahari.

Disainid, millest on peaaegu saanud tarkvara mõne loogika/mehhanismi/tehnika kodeerimise standardviis, on seetõttu hakatud nimetama – ja seega – uuritud tarkvarakujundusmustritena.

Miks on disainimuster oluline?

Põhimõtteliselt kahel põhjusel:

1. Et jääda standardi juurde
2. Arengu kiirendamiseks

Selgitan üksikasjalikult.

Esiteks näeme, miks standardmustri järgimine on huvitav.

Võtame näiteks CV-de loendi, millest me varem rääkisime.

Võib olla üks või kaks kandidaati, kes saadavad oma töötaotlused meilitekstiga ilma korraliku vorminguta, ilma e-kirjade manusteta jne, .. need üks või kaks taotlejat ei järgi mustrit. ja EI tõenäoliselt lõpeta tööga…. miks? Sest nad kalduvad kõrvale väljakujunenud mustrist, mis ei pruugi meeldida inimestele, kes valivad tööülesannete nimekirja.

Kas pole kedagi, kes kaldub mustrist kõrvale ja muutub “lahedaks”? Kas see pole mitte innovatsioon?

Jah, on aegu, kus väga erinevalt esitatud CV saab töö selle eest, et erineb teistest. Tavaliselt olen kuulnud veebidisaineritest, kes sattusid parimatele töökohtadele, kuna nad koostasid ja esitlesid oma töödest CD-filmi või tegid oma tööd selgitava animatsioonitegelase, olid selle oma blogisse üles pannud ja muud taolist.

Aga.. see on eksperimenteerimine (Innovatsioon tuleb edukatest katsetest).

Tarkvaraarenduses ei saa te enamasti lubada katsetamist ajajoone surve, ootuste jms tõttu, kuid jah, mõnikord võimaldavad mõned huvitavad projektid katsetada.

Tarkvaras ei saa me teha põhilisi asju, nagu pangahoius… 101 viisil… pangahoiuse töötlemiseks on vaid mõned viisid. Seega on mõttekas järgida väljakujunenud ja testitud mustrit.

Samuti on enamikul disainimustritel variatsioonid… mõned variatsioonid on nii populaarsed, et variatsioonid on ka uus mustri standardtüüp.

Tänapäeval eeldatakse, et tarkvaraprojektid järgivad (vähemalt kaudselt) turul juba väljakujunenud sarnase toote/tarkvara disaini.

See on koht, kus standardse kodeerimisstiili või kujundusmustri järgimine aitab tarkvaraarendust … kiirendada arendust, eemaldada liigsed kulud uue testimata teostuse pärast muretsemisest jne.

Kinnitus arendusaeg

Standardse kujundusmustri järgimise eeliseks on ka lihtne suhtlemine tarkvaraarhitektide, mooduli juhtide, meeskonnajuhtide, arendajate jne puu/hierarhia kaudu, teemal “Kuidas” on vaja midagi arendada, mitte ainult “Mida” arenenud.

Mõnikord aitab see isegi testimismeeskondi, sest testijad teavad oma kogemusest, et teatud kujundusmustreid järgivat koodi saab tõenäoliselt teatud aja jooksul testimisriistade komplektiga kindlal viisil testida ja sellistel tuntud kujundustel ei pruugi olla mingeid vigu. või neil on “tuntud” puudused.

Kas disainimustrite kasutamine ei anna isikupära?

Ei. Esiteks sellepärast, et me ei ütle, et järgite disainimustrit ja midagi muud ei juhtu. Enamik projektirakendusi jagab ainult põhinõudeid teiste projektidega ja neil on tõenäoliselt kõrvalekaldeid. Nende kõrvalekallete loomine nõuab juurutamisel kasutatavate standardmustrite painutamist ja venitamist.

See on nagu pitsa valmistamine tavalisel viisil, seejärel selle maitsestamine / erinevate nõuete esitamine, kas näiteks täispirukapitsa või lõigatud pirukas või mis iganes.

Disainimustrite tähtsuse mõistmisel on üks asi vägaoluline :

Disainimustrid ei ole tehnoloogia või raamistik, mida konkreetne ettevõte või programmeerimiskeel meile peale surub. See tähendab, et see on nagu avatud kontseptsioon. Sa võid seda vabalt võtta, kasutada, muuta seda vastavalt oma vajadustele ja mis kõige tähtsam… tunda seda enda omana.

Kõik standardsed või populaarsed disainimustrid on tegelikult üsna tugevalt pikendatavad.. need said populaarseks esiteks ainult seetõttu, et paljud inimesed seda kasutavad.. ja paljud kasutavad seda ainult seetõttu, et nad on oma nõudmistele paindlikud.

Või kuidas arvate, kuidas standardne kujundusmuster sobiks projektiga New Jerseys ettevõtte jaoks ja ka Bangalore’is erineva ettevõtte ja erinevat tüüpi projekti jaoks.

See viib meid juurde ” Enamik disainimustreid on üldised “… mis tähendab, et neid ei kasutata alati sama tüüpi tarkvara koostamiseks. Te ei pruugi tavalistes aruteludes kuulda selliseid asju nagu „Pangatarkvara kujundamise muster” või „Sotsiaalvõrgustiku tarkvara kujundamise muster”, vaid ainult „Kujundusmustrid”.

Kes peaks disainimustrite pärast häirima?

1. Nii nagu hea hoonearhitekt arendab oma oskusi hoonete projekteerimisel, peaks tarkvaraarhitekt uurima oma elu jooksul paljude hoonete ja kujundite arhitektuuri ja disaini ning uurima ja visualiseerima, kuidas projekteeritakse erinevaid tarkvara/tehnoloogia süsteeme üle maailma või arhitektuur.
2. Ja nagu ka seda, kuidas hoone ehitustöölised peaksid olema teadlikud erinevatest ehitusprojekti elluviimise viisidest kas oma kogemusest või hoone arhitektilt aru saades.

Tarkvaraarendajad/programmeerijad peaksid mõistma põhilisi tarkvara kujundamise mustreid ja nende rakenduskoodi… kas ise või tarkvaraarhitektilt, kes juhendab meeskonda seda konkreetse mustri järgi välja töötama.

Põhikoodimustrid

Selle artikli avareas ütlesin, et iga programmeerija oleks kasutanud disainimustreid. Siin on mõned väga lihtsad näited mustrit järgiva koodi kohta.

1. Järgmine on pealtkuulamisfiltri kujundusmuster.

2. Peida kopeeri kood

3. switch (condition){
        case Value1:
        case Value2:
        default:
   }

4. Sündmuste käivitajad, sündmuste käitlejad… kuuluvad subjekti-vaatleja põhimustri alla. Arutame iga mustri standardeid, populaarseid variatsioone koos näidetega … varsti.

5. Kui olete kasutanud mõnda tüüpi kogusid, näiteks C#-s Arraylist, ja itereerinud massiivi kaudu, siis olete kasutanud Iteratori põhikujundusmustrit.

6. Allolev kood on näide põhilisest erandite käsitlemise / vastutusahela mustrist.

7. Peida kopeeri kood

8. try{
   }catch(Exception ex){
   }
   finally{
   }

Disainimustrite erinevad valdkonnad

Tarkvaras on erinevaid terminoloogiaid peale disainimustrite. mõned neist on sageli seotud disainimustritega, mida oleme seni arutanud. ja mõned neist pole täiesti seotud.

Seda, mida oleme siiani eespool arutanud, nimetatakse mõnikord ” rakenduse disaini mustriteks “.

On ka teisi, nagu arhitektuurimustrid, raammustrid, keelemustrid (enamasti nimetatakse neid keelekonstruktsioonideks).

Need on erinevatel tasanditel laotud mustrid… nagu Keelemustrid on mustrid, mida rakendatakse osana programmeerimiskeeltest nagu C# / Java, kui keele funktsioonid/konstruktsioonid.. mõnda neist oleme juba näinud.

Kõik ülaltoodud näited subjekti-vaatlejast, pealtkuulavast filtrist jne on keelekonstruktsioonidena kõigis populaarsetes kõrgetasemelistes programmeerimiskeeltes, mis ilmusid pärast C.

Arhitektuurimustrid on need tarkvaraarhitektuuri standardmudelid, mis tavaliselt viitavad erinevatele moodulite või kihtide või tasandite paigutamise või ühendamise meetoditele, mis moodustavad kogu rakenduse.

See ei ole kodeerimise/programmeerimise mõttes disainimustritega täiesti seotud, kuid neil on samad vastused küsimusele Miks / Mis on, nagu selles artiklis käsitletud.

Raammustrid ei ole samuti seotud meie aruteluga disainimustrite üle. Kui raamistikud, nagu .NET, rakendavad spetsiaalseid vahendeid vigade logimiseks või koodi täitmismarsruutide jälgimiseks raamistiku sisseehitatud meetodite või objektide kaudu, nimetatakse selliseid mehhanisme raamistiku mustriteks.

Mõned .NET Frameworki näited hõlmavad funktsiooni stackTrace, klassi atribuudi funktsiooni [] nurksulgudega klassi/meetodi definitsioonide kohal jne. Selliste funktsioonide kasutamisel kodeerime raamistiku sisseehitatud mustritega.

Loodan, et see artikkel aitab anda ülevaate disainimustritest ja nendega seotud terminoloogiatest.

Siiani arutasime ainult seda, mis on standardid ja kui olulised need on.. aga me ei arutanud, millised on standardmustrid ise.

Litsents

See artikkel koos kõigi seotud lähtekoodide ja failidega on litsentsitud koodiprojekti avatud litsentsi (CPOL) alusel.