Designmodeller for nybegynnere

Hvis du allerede har skrevet programmer for produkter eller programvareapplikasjoner, store/små, er det mest sannsynlig at du har brukt mange designmønstre… selv om det er mulig at de kanskje ikke er et av de mest brukte/standard designmønstrene.

Men ja, det er en åpenbar forskjell mellom å implementere et designmønster og «bruke» et designmønster… uansett, personen som jobber med designmønstre forstår det, eller vil forstå det lett.

Poenget er at designmønstre ikke er nye for programmerere.

I denne artikkelen nedenfor prøver jeg å forklare designmønstre i dets grunnleggende, og vi vil studere detaljer om forskjellige mønstre, eksempler osv. i en annen artikkel.

Hva er et designmønster?

Å begynne…

Jeg tror den beste måten å begynne med å forstå designmønstre er ved å forstå ikke-tekniske mønstre som vi bevisst / ubevisst følger i hverdagen vår.

La oss for eksempel ta mange CV-er som er sendt inn for en ledig stilling. Alles CV ser ikke like ut … selv om de alle pleier å gjøre det samme, det er å fortelle en leser hva de er dyktige på, eller hvordan han/hun kan passe for jobben.

Flertallet av dem som sender inn CV til jobber, vet at de må sende inn en CV med et bestemt sett med informasjon i et formatert Word-dokument.

Dette … er et mønster, at alle sender inn et CV med et bestemt sett med informasjon uttrykt i den.

Hvis du har lyst… kall det maler i stedet for mønstre. Designmaler.

Det er mange slike ting i det virkelige liv som er mønstre. Noen liker eksemplene nedenfor:

Alle kokker over hele verden lager pizza eller pommes frites på samme måte. Selv om de kan toppe det / smaksette det annerledes. Det er et mønster.

Hver bils design følger et grunnleggende designmønster, fire hjul, ratt, kjernedrivsystemet som gasspedal-break-clutch, etc.

Alle ting som bygges/produseres gjentatte ganger, skal uunngåelig følge et mønster i designet… det være seg biler, pizza, minibanker, hva som helst… til og med tannbørste.

Design som nesten har blitt en standard måte å kode logikk/mekanismer/teknikker i programvare, blir derfor kjent som – og dermed – studert som Software Design Patterns.

Hvorfor er et designmønster viktig?

I utgangspunktet av to grunner:

1. For å holde seg til en standard
2. For å få fart på utviklingen

Jeg vil forklare i detalj.

For det første ser vi hvorfor det er interessant å holde seg til et standardmønster.

La oss ta listen over CV-eksempler vi diskuterte før.

Det kan være en eller to søkere som sender jobbsøknadene sine på e-post uten riktig formatering, uten vedlegg til e-posten, osv., .. disse en eller to søkerne følger ikke mønsteret.. og vil sannsynligvis IKKE ende opp med jobben…. Hvorfor? Fordi de avviker fra et veletablert mønster, som kanskje ikke er likt av de som søker CV-er for jobben.

Er det ikke noen som avviker fra mønsteret og blir «kule»? Er ikke det innovasjon?

Ja, det er tider at en veldig annerledes presentert CV får jobben for å være annerledes enn de andre. Vanligvis har jeg hørt om webdesignere som fikk toppjobber fordi de kompilerte og presenterte en CD-film av arbeidet sitt, eller laget en animasjonsfigur som forklarer arbeidet deres, hadde lagt det ut på bloggen deres og slike ting.

Men.. dette er eksperimentering (innovasjon kommer fra vellykkede eksperimenter).

Oftest i programvareutvikling har du ikke råd til å eksperimentere, på grunn av tidslinjepress, forventninger osv., men ja noen ganger, noen interessante prosjekter tillater litt eksperimentering.

I programvare kan vi ikke gjøre grunnleggende ting som et bankinnskudd… på 101 måter… det vil bare være noen få måter å behandle et bankinnskudd på… så det er fornuftig å følge et etablert og testet mønster.

Dessuten har de fleste designmønstre variasjoner … noen av variantene er så populære at variantene også vil være en ny standardtype av mønsteret.

Programvareprosjekter i disse dager forventes (i det minste implisitt) å følge en allerede etablert design av et lignende produkt/programvare på markedet.

Det er her det å holde seg til en standard stil med koding eller designmønster hjelper programvareutvikling … å feste utviklingen, fjerne overheaden med å bekymre seg for en ny utestet implementering, etc.,

Feste utviklingstid

Å følge et standard designmønster har også fordelen av å kommunisere enkelt gjennom treet / hierarkiet av programvarearkitekter, modulleads, team leads, Developers etc., om «Hvordan» noe må utvikles, og ikke bare «Hva» må være utviklet.

Noen ganger hjelper det til og med Testing Teams, fordi testere ville vite av erfaring at kode som følger et bestemt designmønster sannsynligvis kan testes på en bestemt måte med et sett med testverktøy i en viss tidsperiode, og slike kjente design har kanskje ikke noen feil eller har noen «kjente» feil.

Får ikke bruk av Design Patterns et personlig preg?

Nei. For det første fordi vi ikke sier at du følger et designmønster og at ingenting annet skjer. De fleste prosjektimplementeringer deler bare grunnleggende krav med andre prosjekter, og vil mest sannsynlig ha avvik. Å bygge disse avvikene vil kreve å bøye og strekke standardmønstrene som brukes i en implementering.

Det er som å lage pizzaen på standardmåten, for så å smaksette den / presentere den til forskjellige krav, enten som en helpai-pizza, eller en oppskåret pai, eller hva som helst.

Når det gjelder å forstå viktigheten av designmønstre, er én ting veldigviktig :

Designmønstre er ikke noen teknologi eller rammeverk som et bestemt selskap eller programmeringsspråk tvinger på oss. Det betyr at det er som et åpent konsept… du står fritt til å ta det, bruke det, modifisere det til dine behov, og viktigst av alt… føle det ditt eget.

Alle standard eller populære designmønstre kan faktisk utvides ganske tungt.. de ble populære, for det første, bare fordi mange bruker det.. og mange bruker det bare fordi de er fleksible etter deres krav.

Eller hvordan tror du et standard designmønster vil passe til et prosjekt i New Jersey for et selskap og også i Bangalore for et annet selskap og en annen type prosjekt.

Det bringer oss til » De fleste designmønstre er generiske » … betyr at de ikke alltid brukes til å bygge samme type programvare. Du hører kanskje ikke ting som «designmønster for bankprogramvare» eller «designmønster for sosiale nettverksprogramvare» brukt i vanlige diskusjoner … men bare «designmønstre».

Hvem bør bry seg om designmønstre?

1. Akkurat som hvordan en god bygningsarkitekt øker ferdighetene sine med å designe bygninger, ved å studere arkitekturen og designen til en rekke bygninger og former gjennom livet, bør en programvarearkitekt studere og visualisere hvordan forskjellige programvare-/teknologisystemer over hele kloden er designet eller arkitekttisert.
2. Og akkurat som hvordan bygningsarbeiderne i et bygg bør være oppmerksomme på ulike måter å implementere en bygningsdesign på, enten fra egen erfaring eller ved å forstå det fra Byggets Arkitekt.

Programvareutviklere/programmerere bør forstå grunnleggende programvaredesignmønstre og implementeringskoden deres… enten selv eller fra programvarearkitekten som instruerer teamet til å utvikle det etter et bestemt mønster.

Grunnleggende kodemønstre

I de innledende linjene i denne artikkelen sa jeg at enhver programmerer ville ha brukt designmønstre. Her er noen veldig grunnleggende eksempler på kode som følger et mønster.

1. Følgende er et grunnleggende designmønster for intercepting filter .

2. Skjul kopier kode

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

4. Hendelsesutløsere, hendelsesbehandlere.. kommer under grunnleggende Emne-Observer designmønster. Vi vil diskutere hver mønsterstandard, populære varianter, med eksempler… snart.

5. Hvis du har brukt en slags samlinger, som Arraylist i C#, og itererer gjennom arrayet, har du brukt et grunnleggende Iterator -designmønster.

6. Koden nedenfor er et eksempel på et grunnleggende unntakshåndtering/ ansvarskjedemønster.

7. Skjul kopier kode

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

Ulike områder av designmønstre

Det er andre terminologier i programvare enn Design Patterns.. noen av dem er ofte relatert til designmønstre som vi har diskutert så langt.. og noen av dem er helt uten slekt.

Det vi så langt har diskutert ovenfor kalles noen ganger » Implementation Design Patterns «.

Det er andre, som arkitekturmønstre, rammemønstre, språkmønstre (for det meste kalt språkkonstruksjoner).

De er mønstre lagt på forskjellige nivåer … som Språkmønstre er mønstre implementert som en del av programmeringsspråk som C# / Java, som språkets funksjoner / konstruksjoner. Noen av dem har vi allerede sett.

Alle eksemplene ovenfor på subjektobservatør, avskjærende filter, etc., er absorbert som språkkonstruksjoner i alle populære programmeringsspråk på høyt nivå som kom etter C.

Arkitekturmønstre er de standardmodellene for programvarearkitektur, som vanligvis refererer til forskjellige metoder for å plassere eller koble moduler eller lag eller lag, som utgjør hele applikasjonen.

Dette er helt urelatert til designmønstre i betydningen koding/programmering som … men de deler de samme svarene på hvorfor / hva er som diskutert i denne artikkelen.

Rammemønstre er heller ikke relatert til vår diskusjon om designmønstre. Når rammeverk som .NET implementerer spesielle midler for logging av feil eller sporing av kodekjøringsruter enkelt gjennom rammeverkets innebygde metoder eller objekter, refereres slike mekanismer til som rammemønstre.

Noen eksempler i .NET Framework inkluderer stackTrace-funksjonen, klasseattributt-funksjonen med [] firkantede klammeparenteser på toppen av klasse-/metodedefinisjoner osv. Når vi bruker slike funksjoner, koder vi med Frameworks innebygde mønstre.

Jeg håper denne artikkelen bidrar til å gi en oversikt over designmønstre og relaterte terminologier.

Så langt har vi bare diskutert hva standardene er og hvor viktige de er.. men vi diskuterte ikke hva selve standardmønstrene er.

Tillatelse

Denne artikkelen, sammen med all tilknyttet kildekode og filer, er lisensiert under The Code Project Open License (CPOL).