Modeller av design för nybörjare

Om du redan har skrivit program för produkter eller mjukvaruapplikationer, stora/små, har du med största sannolikhet använt många designmönster… även om det är möjligt att de kanske inte är ett av de mest använda/standardiserade designmönstren.

Men ja, det finns en uppenbar skillnad mellan att implementera ett designmönster och att ”använda” ett designmönster… i vilket fall som helst, personen som arbetar med designmönster förstår det, eller kommer att förstå det lätt.

Poängen är att designmönster inte är nytt för programmerare.

I den här artikeln nedan försöker jag förklara designmönster, i dess grunder, och vi kommer att studera detaljer om olika mönster, exempel etc. i en annan artikel.

Vad är ett designmönster?

Att börja…

Jag tror att det bästa sättet att börja med att förstå designmönster är att förstå icke-tekniska mönster som vi medvetet/omedvetet följer i vår vardag.

Låt oss till exempel ta många CV som skickats in för ett ledigt jobb. Allas CV ser inte likadant ut… även om de alla tenderar att göra samma sak, det vill säga att berätta för en läsare vad de är skickliga på, eller hur han/hon kan vara lämplig för jobbet.

Majoriteten av dem som skickar CV till jobb vet att de måste skicka in ett CV med en viss uppsättning information i ett formaterat Word-dokument.

Detta… är ett mönster, att alla skickar in ett CV med en viss uppsättning information uttryckt i den.

Om du känner för… kalla det mallar istället för mönster. Designmallar.

Det finns många sådana saker i verkliga livet som är mönster. Vissa gillar följande exempel:

Alla kockar runt om i världen lagar pizza eller pommes frites på samma sätt. Även om de kan toppa det / smaksätta det annorlunda. Det är ett mönster.

Varje bils design följer ett grundläggande designmönster, fyra hjul, ratt, kärndrivsystemet som gaspedalen-bryt-koppling, etc.

Alla saker som byggs/produceras upprepade gånger kommer oundvikligen att följa ett mönster i sin design… vare sig det är bilar, pizza, bankomater, vad som helst… till och med tandborste.

Design som nästan har blivit ett standardsätt att koda någon logik/mekanism/teknik i mjukvara, kommer därför att kallas – och följaktligen – studeras som Software Design Patterns.

Varför är ett designmönster viktigt?

I grund och botten av två skäl:

1. Att hålla sig till en standard
2. För att snabba på utvecklingen

Jag kommer att förklara i detalj.

För det första ser vi varför det är intressant att hålla sig till ett standardmönster.

Låt oss ta listan med exempel på CV som vi diskuterade tidigare.

Det kan finnas en eller två sökande som skickar sina jobbansökningar via e-post utan korrekt formatering, utan bilagor till sin e-post, etc., .. dessa en eller två sökande följer inte mönstret.. och kommer sannolikt INTE att hamna med jobbet…. Varför? Eftersom de avviker från ett väletablerat mönster, som kanske inte gillas av de personer som listar CV för jobbet.

Är det ingen som avviker från mönstret och blir ”cool”? Är inte det innovation?

Ja, det finns tillfällen då ett mycket annorlunda presenterat CV får jobbet för att vara annorlunda än de andra. Vanligtvis har jag hört talas om webbdesigners som fick bra jobb för att de kompilerade och presenterade en cd-film av sitt arbete, eller gjorde en animationsfigur som förklarade sitt arbete, hade lagt upp det på sin blogg och liknande.

Men.. detta är experimenterande (Innovation kommer från framgångsrika experiment).

Oftast inom mjukvaruutveckling har du inte råd att experimentera, på grund av tidslinjepress, förväntningar etc., men ja ibland, vissa intressanta projekt tillåter viss experimentering.

I mjukvara kan vi inte göra grundläggande saker som en bankinsättning… på 101 sätt… det kommer bara att finnas några få sätt att behandla en bankinsättning… så det är vettigt att följa ett etablerat och testat mönster.

Dessutom har de flesta designmönster variationer… några av varianterna är så populära att varianterna också kommer att vara en ny standardtyp av mönstret.

Programvaruprojekt i dessa dagar förväntas (åtminstone implicit) följa en redan etablerad design av en liknande produkt/mjukvara på marknaden.

Det är här att hålla fast vid en standardstil av kodning eller designmönster hjälper mjukvaruutveckling … att fästa utvecklingen, ta bort kostnaderna för att oroa sig för en ny oprövad implementering, etc.,

Fästande utvecklingstid

Att följa ett standarddesignmönster har också fördelen av att enkelt kommunicera genom trädet/hierarkin av mjukvaruarkitekter, modulleads, team leads, Developers etc., om ”Hur” något behöver utvecklas, och inte bara ”vad” måste vara tagit fram.

Ibland hjälper det till och med testteam, eftersom testare av erfarenhet skulle veta att kod som följer ett visst designmönster förmodligen skulle kunna testas på ett specifikt sätt med en uppsättning testverktyg under en viss tidsperiod, och sådana kända konstruktioner kanske inte har några brister eller har några ”kända” brister.

Tar inte designmönster en personlig touch?

Nej. För det första för att vi inte säger att du följer ett designmönster och inget annat händer. De flesta projektimplementeringar delar bara grundläggande krav med andra projekt och kommer med största sannolikhet att ha avvikelser. Att bygga dessa avvikelser kommer att kräva att de standardmönster som används i en implementering böjs och sträcks ut.

Det är som att göra pizzan på vanligt sätt, sedan smaksätta den/presentera den till olika krav, antingen som en helpajspizza, eller en skuren paj eller vad som helst.

För att förstå vikten av designmönster är en sak mycketviktigt :

Designmönster är inte någon teknik eller ramverk som ett visst företag eller programmeringsspråk tvingar på oss. Det betyder att det är som ett öppet koncept… du är fri att ta det, använda det, modifiera det efter dina behov, och viktigast av allt… känna det ditt eget.

Alla vanliga eller populära designmönster är faktiskt utdragbara ganska kraftigt.. de blev populära, för det första, bara för att många människor använder det.. och många människor använder det bara för att de är flexibla för deras krav.

Eller hur tror du att ett standarddesignmönster skulle passa ett projekt i New Jersey för ett företag och även i Bangalore för ett annat företag och en annan typ av projekt.

Det leder oss till ” De flesta designmönster är generiska ”… vilket innebär att de inte alltid används för att bygga samma typ av programvara. Du kanske inte hör saker som ”designmönster för bankprogram” eller ”designmönster för sociala nätverksprogram” som används i vanliga diskussioner… utan bara ”designmönster”.

Vem borde bry sig om designmönster?

1. Precis som hur en bra byggnadsarkitekt utvecklar sina färdigheter att designa byggnader, genom att studera arkitekturen och designen av många byggnader och former under hela sitt liv, bör en mjukvaruarkitekt studera och visualisera hur olika mjukvaru-/tekniksystem över hela världen är designade eller arkitektonerade.
2. Och precis som hur byggnadsarbetarna i en byggnad bör vara medvetna om olika sätt att implementera en byggnadsdesign, antingen utifrån sin egen erfarenhet eller genom att förstå det från byggnadens arkitekt.

Mjukvaruutvecklare/programmerare bör förstå grundläggande mjukvarudesignmönster och deras implementeringskod… antingen själva eller från mjukvaruarkitekten som instruerar teamet att utveckla det enligt ett visst mönster.

Grundläggande kodmönster

I början av den här artikeln sa jag att vilken programmerare som helst skulle ha använt designmönster. Här är några mycket grundläggande exempel på kod som följer ett mönster.

1. Följande är ett grundläggande designmönster för Intercepting Filter .

2. Dölj kopiera kod

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

4. Händelseutlösare, Händelsehanterare… kommer under det grundläggande designmönster för ämne-observatörer . Vi kommer att diskutera varje mönsterstandard, populära varianter, med exempel… snart.

5. Om du har använt någon form av samlingar, som Arraylist i C#, och itererar genom arrayen, så har du använt ett grundläggande Iterator- designmönster.

6. Koden nedan är ett exempel på ett grundläggande mönster för undantagshantering/ ansvarskedja.

7. Dölj kopiera kod

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

Olika områden av designmönster

Det finns olika terminologier i programvara förutom Design Patterns.. några av dem är ofta relaterade till designmönster som vi hittills har diskuterat.. och några av dem är helt orelaterade.

Det vi hittills har diskuterat ovan kallas ibland ” Implementation Design Patterns ”.

Det finns andra, som arkitekturmönster, rammönster, språkmönster (oftast kallade språkkonstruktioner).

De är mönster som läggs på olika nivåer… som Språkmönster är mönster implementerade som en del av programmeringsspråk som C#/Java, som språkets egenskaper/konstruktioner.. några av dem har vi redan sett.

Alla ovanstående exempel på subjektobservatör, avlyssningsfilter, etc., absorberas som språkkonstruktioner i alla populära högnivåprogrammeringsspråk som kom efter C.

Arkitekturmönster är dessa standardmodeller av programvaruarkitektur, som vanligtvis hänvisar till olika metoder för att placera eller länka moduler eller lager eller nivåer, som utgör hela applikationen.

Detta är helt utan samband med designmönster i betydelsen kodning/programmering som… men de delar samma svar på Varför / Vad är som diskuteras i den här artikeln.

Rammönster är inte heller relaterade till vår diskussion om designmönster. När ramverk som .NET implementerar speciella metoder för att logga fel eller spåra kodexekveringsvägar enkelt genom ramverkets inbyggda metoder eller objekt, kallas sådana mekanismer för rammönster.

Några exempel i .NET Framework inkluderar stackTrace-funktionen, klassattributsfunktionen med [] fyrkantiga klammerparenteser ovanpå klass-/metoddefinitioner, etc. När vi använder sådana funktioner kodar vi med Frameworks inbyggda mönster.

Jag hoppas att den här artikeln hjälper till att ge en översikt över designmönster och relaterade terminologier.

Hittills har vi bara diskuterat vad standarderna är och hur viktiga de är… men vi har inte diskuterat vilka standardmönstren i sig är.

Licens

Den här artikeln, tillsammans med all tillhörande källkod och filer, är licensierad under The Code Project Open License (CPOL).