\n Hvis du allerede har skrevet programmer for produkter eller programvareapplikasjoner, store\/sm\u00e5, er det mest sannsynlig at du har brukt mange designm\u00f8nstre… selv om det er mulig at de kanskje ikke er et av de mest brukte\/standard designm\u00f8nstrene.\n<\/p>\n
\n Men ja, det er en \u00e5penbar forskjell mellom \u00e5 implementere et designm\u00f8nster og «bruke» et designm\u00f8nster… uansett, personen som jobber med designm\u00f8nstre forst\u00e5r det, eller vil forst\u00e5 det lett.\n<\/p>\n
\n Poenget er at designm\u00f8nstre ikke er nye for programmerere.\n<\/p>\n
\n I denne artikkelen nedenfor pr\u00f8ver jeg \u00e5 forklare designm\u00f8nstre i dets grunnleggende, og vi vil studere detaljer om forskjellige m\u00f8nstre, eksempler osv. i en annen artikkel.\n<\/p>\n
\n Hva er et designm\u00f8nster?\n<\/p>\n
\n \u00c5 begynne\u2026<\/strong>\n<\/p>\n \n Jeg tror den beste m\u00e5ten \u00e5 begynne med \u00e5 forst\u00e5 designm\u00f8nstre er ved \u00e5 forst\u00e5 ikke-tekniske m\u00f8nstre som vi bevisst \/ ubevisst f\u00f8lger i hverdagen v\u00e5r.\n<\/p>\n \n 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 \u00e5 gj\u00f8re det samme, det er \u00e5 fortelle en leser hva de er dyktige p\u00e5, eller hvordan han\/hun kan passe for jobben.\n<\/p>\n \n Flertallet av dem som sender inn CV til jobber, vet at de m\u00e5 sende inn en CV med et bestemt sett med informasjon i et formatert Word-dokument.\n<\/p>\n \n Dette … er et m\u00f8nster, at alle sender inn et CV med et bestemt sett med informasjon uttrykt i den.\n<\/p>\n \n Hvis du har lyst… kall det maler i stedet for m\u00f8nstre. Designmaler.\n<\/p>\n \n Det er mange slike ting i det virkelige liv som er m\u00f8nstre. Noen liker eksemplene nedenfor:\n<\/p>\n \n Alle kokker over hele verden lager pizza eller pommes frites p\u00e5 samme m\u00e5te. Selv om de kan toppe det \/ smaksette det annerledes. Det er et m\u00f8nster.\n<\/p>\n \n Hver bils design f\u00f8lger et grunnleggende designm\u00f8nster, fire hjul, ratt, kjernedrivsystemet som gasspedal-break-clutch, etc.\n<\/p>\n \n Alle ting som bygges\/produseres gjentatte ganger, skal uunng\u00e5elig f\u00f8lge et m\u00f8nster i designet… det v\u00e6re seg biler, pizza, minibanker, hva som helst… til og med tannb\u00f8rste.\n<\/p>\n \n Design som nesten har blitt en standard m\u00e5te \u00e5 kode logikk\/mekanismer\/teknikker i programvare, blir derfor kjent som \u2013 og dermed \u2013 studert som Software Design Patterns.\n<\/p>\n \n I utgangspunktet av to grunner:\n<\/p>\n \n Jeg vil forklare i detalj.\n<\/p>\n \n For det f\u00f8rste ser vi hvorfor det er interessant \u00e5 holde seg til et standardm\u00f8nster.\n<\/p>\n \n La oss ta listen over CV-eksempler vi diskuterte f\u00f8r.\n<\/p>\n \n Det kan v\u00e6re en eller to s\u00f8kere som sender jobbs\u00f8knadene sine p\u00e5 e-post uten riktig formatering, uten vedlegg til e-posten, osv., .. disse en eller to s\u00f8kerne f\u00f8lger ikke m\u00f8nsteret.. og vil sannsynligvis IKKE ende opp med jobben…. Hvorfor? Fordi de avviker fra et veletablert m\u00f8nster, som kanskje ikke er likt av de som s\u00f8ker CV-er for jobben.\n<\/p>\n \n Ja, det er tider at en veldig annerledes presentert CV f\u00e5r jobben for \u00e5 v\u00e6re annerledes enn de andre. Vanligvis har jeg h\u00f8rt 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\u00e5 bloggen deres og slike ting.\n<\/p>\n \n Men.. dette er eksperimentering (innovasjon kommer fra vellykkede eksperimenter).\n<\/p>\n \n Oftest i programvareutvikling har du ikke r\u00e5d til \u00e5 eksperimentere, p\u00e5 grunn av tidslinjepress, forventninger osv., men ja noen ganger, noen interessante prosjekter tillater litt eksperimentering.\n<\/p>\n \n I programvare kan vi ikke gj\u00f8re grunnleggende ting som et bankinnskudd… p\u00e5 101 m\u00e5ter… det vil bare v\u00e6re noen f\u00e5 m\u00e5ter \u00e5 behandle et bankinnskudd p\u00e5… s\u00e5 det er fornuftig \u00e5 f\u00f8lge et etablert og testet m\u00f8nster.\n<\/p>\n \n Dessuten har de fleste designm\u00f8nstre variasjoner … noen av variantene er s\u00e5 popul\u00e6re at variantene ogs\u00e5 vil v\u00e6re en ny standardtype av m\u00f8nsteret.\n<\/p>\n \n Programvareprosjekter i disse dager forventes (i det minste implisitt) \u00e5 f\u00f8lge en allerede etablert design av et lignende produkt\/programvare p\u00e5 markedet.\n<\/p>\n \n Det er her det \u00e5 holde seg til en standard stil med koding eller designm\u00f8nster hjelper programvareutvikling … \u00e5 feste utviklingen, fjerne overheaden med \u00e5 bekymre seg for en ny utestet implementering, etc.,\n<\/p>\n \n \u00c5 f\u00f8lge et standard designm\u00f8nster har ogs\u00e5 fordelen av \u00e5 kommunisere enkelt gjennom treet \/ hierarkiet av programvarearkitekter, modulleads, team leads, Developers etc., om «Hvordan» noe m\u00e5 utvikles, og ikke bare «Hva» m\u00e5 v\u00e6re utviklet.\n<\/p>\n \n Noen ganger hjelper det til og med Testing Teams, fordi testere ville vite av erfaring at kode som f\u00f8lger et bestemt designm\u00f8nster sannsynligvis kan testes p\u00e5 en bestemt m\u00e5te med et sett med testverkt\u00f8y i en viss tidsperiode, og slike kjente design har kanskje ikke noen feil eller har noen «kjente» feil.\n<\/p>\n \n Nei. For det f\u00f8rste fordi vi ikke sier at du f\u00f8lger et designm\u00f8nster og at ingenting annet skjer. De fleste prosjektimplementeringer deler bare grunnleggende krav med andre prosjekter, og vil mest sannsynlig ha avvik. \u00c5 bygge disse avvikene vil kreve \u00e5 b\u00f8ye og strekke standardm\u00f8nstrene som brukes i en implementering.\n<\/p>\n \n Det er som \u00e5 lage pizzaen p\u00e5 standardm\u00e5ten, for s\u00e5 \u00e5 smaksette den \/ presentere den til forskjellige krav, enten som en helpai-pizza, eller en oppsk\u00e5ret pai, eller hva som helst.\n<\/p>\n \n N\u00e5r det gjelder \u00e5 forst\u00e5 viktigheten av designm\u00f8nstre, er \u00e9n ting veldigviktig<\/strong> :\n<\/p>\n \n Designm\u00f8nstre er ikke noen teknologi eller rammeverk som et bestemt selskap eller programmeringsspr\u00e5k tvinger p\u00e5 oss. Det betyr at det er som et \u00e5pent konsept… du st\u00e5r fritt til \u00e5 ta det, bruke det, modifisere det til dine behov, og viktigst av alt… f\u00f8le det ditt eget.\n<\/p>\n \n Alle standard eller popul\u00e6re designm\u00f8nstre kan faktisk utvides ganske tungt.. de ble popul\u00e6re, for det f\u00f8rste, bare fordi mange bruker det.. og mange bruker det bare fordi de er fleksible etter deres krav.\n<\/p>\n \n Eller hvordan tror du et standard designm\u00f8nster vil passe til et prosjekt i New Jersey for et selskap og ogs\u00e5 i Bangalore for et annet selskap og en annen type prosjekt.\n<\/p>\n \n Det bringer oss til » De fleste designm\u00f8nstre er generiske<\/strong> » … betyr at de ikke alltid brukes til \u00e5 bygge samme type programvare. Du h\u00f8rer kanskje ikke ting som «designm\u00f8nster for bankprogramvare» eller «designm\u00f8nster for sosiale nettverksprogramvare» brukt i vanlige diskusjoner … men bare «designm\u00f8nstre».\n<\/p>\n \n Programvareutviklere\/programmerere b\u00f8r forst\u00e5 grunnleggende programvaredesignm\u00f8nstre og implementeringskoden deres… enten selv eller fra programvarearkitekten som instruerer teamet til \u00e5 utvikle det etter et bestemt m\u00f8nster.\n<\/p>\n \n I de innledende linjene i denne artikkelen sa jeg at enhver programmerer ville ha brukt designm\u00f8nstre. Her er noen veldig grunnleggende eksempler p\u00e5 kode som f\u00f8lger et m\u00f8nster.\n<\/p>\n \n F\u00f8lgende er et grunnleggende designm\u00f8nster for intercepting filter .<\/strong>\n <\/p>\n<\/li>\n \n Skjul kopier kode\n <\/p>\n<\/li>\n \n Hendelsesutl\u00f8sere, hendelsesbehandlere.. kommer under grunnleggende Emne-Observer<\/strong> designm\u00f8nster. Vi vil diskutere hver m\u00f8nsterstandard, popul\u00e6re varianter, med eksempler… snart.\n <\/p>\n<\/li>\n \n Hvis du har brukt en slags samlinger, som Arraylist i C#, og itererer gjennom arrayet, har du brukt et grunnleggende Iterator<\/strong> -designm\u00f8nster.\n <\/p>\n<\/li>\n \n Koden nedenfor er et eksempel p\u00e5 et grunnleggende unntaksh\u00e5ndtering\/ ansvarskjedem\u00f8nster<\/strong>.\n <\/p>\n<\/li>\n \n Skjul kopier kode\n <\/p>\n<\/li>\n \n Det er andre terminologier i programvare enn Design Patterns.. noen av dem er ofte relatert til designm\u00f8nstre som vi har diskutert s\u00e5 langt.. og noen av dem er helt uten slekt.\n<\/p>\n \n Det vi s\u00e5 langt har diskutert ovenfor kalles noen ganger » Implementation Design Patterns<\/strong> «.\n<\/p>\n \n Det er andre, som arkitekturm\u00f8nstre, rammem\u00f8nstre, spr\u00e5km\u00f8nstre<\/strong> (for det meste kalt spr\u00e5kkonstruksjoner).\n<\/p>\n \n De er m\u00f8nstre lagt p\u00e5 forskjellige niv\u00e5er … som Spr\u00e5km\u00f8nstre<\/strong> er m\u00f8nstre implementert som en del av programmeringsspr\u00e5k som C# \/ Java, som spr\u00e5kets funksjoner \/ konstruksjoner. Noen av dem har vi allerede sett.\n<\/p>\n \n Alle eksemplene ovenfor p\u00e5 subjektobservat\u00f8r, avskj\u00e6rende filter, etc., er absorbert som spr\u00e5kkonstruksjoner i alle popul\u00e6re programmeringsspr\u00e5k p\u00e5 h\u00f8yt niv\u00e5 som kom etter C.\n<\/p>\n \n Arkitekturm\u00f8nstre<\/strong> er de standardmodellene for programvarearkitektur, som vanligvis refererer til forskjellige metoder for \u00e5 plassere eller koble moduler eller lag eller lag, som utgj\u00f8r hele applikasjonen.\n<\/p>\n \n Dette er helt urelatert til designm\u00f8nstre i betydningen koding\/programmering som … men de deler de samme svarene p\u00e5 hvorfor \/ hva er som diskutert i denne artikkelen.\n<\/p>\n \n Rammem\u00f8nstre<\/strong> er heller ikke relatert til v\u00e5r diskusjon om designm\u00f8nstre. N\u00e5r rammeverk som .NET implementerer spesielle midler for logging av feil eller sporing av kodekj\u00f8ringsruter enkelt gjennom rammeverkets innebygde metoder eller objekter, refereres slike mekanismer til som rammem\u00f8nstre.\n<\/p>\n \n Noen eksempler i .NET Framework inkluderer stackTrace-funksjonen, klasseattributt-funksjonen med [] firkantede klammeparenteser p\u00e5 toppen av klasse-\/metodedefinisjoner osv. N\u00e5r vi bruker slike funksjoner, koder vi med Frameworks innebygde m\u00f8nstre.\n<\/p>\n \n Jeg h\u00e5per denne artikkelen bidrar til \u00e5 gi en oversikt over designm\u00f8nstre og relaterte terminologier.\n<\/p>\n \n S\u00e5 langt har vi bare diskutert hva standardene er og hvor viktige de er.. men vi diskuterte ikke hva selve standardm\u00f8nstrene er.\n<\/p>\n \n Denne artikkelen, sammen med all tilknyttet kildekode og filer, er lisensiert under The Code Project Open License (CPOL).\n<\/p>\n<\/p>\n\n Hvorfor er et designm\u00f8nster viktig?
\n<\/h3>\n\n
\n Er det ikke noen som avviker fra m\u00f8nsteret og blir \u00abkule\u00bb? Er ikke det innovasjon?
\n<\/h5>\n\n Feste utviklingstid
\n<\/h5>\n\n F\u00e5r ikke bruk av Design Patterns et personlig preg?
\n<\/h5>\n\n Hvem b\u00f8r bry seg om designm\u00f8nstre?
\n<\/h3>\n\n
\n Grunnleggende kodem\u00f8nstre
\n<\/h3>\n\n
switch (condition){\n case Value1:\n case Value2:\n default:\n}<\/code><\/pre>\n<\/li>\ntry{\n}catch(Exception ex){\n}\nfinally{\n}<\/code><\/pre>\n<\/li>\n<\/ol>\n\n Ulike omr\u00e5der av designm\u00f8nstre
\n<\/h3>\n\n Tillatelse
\n<\/h4>\n