Design mønstre er design-nivå løsninger for tilbakevendende problemer som vi programvare ingeniører kommer over ofte. Det er ikke kode – jeg gjentar, ❌KODE. Det er som en beskrivelse på hvordan de skal takle disse problemene og designe en løsning.
ved Hjelp av disse mønstrene er ansett som god praksis, som utformingen av løsningen er ganske prøvd og testet, noe som resulterer i høyere lesbarheten av den endelige koden., Design-mønstre er ganske ofte skapt for og brukes av OOP Språk som Java, der de fleste av eksemplene fra dette vil bli skrevet.
Typer design mønstre
Det er ca 26 Mønstre i dag oppdaget jeg neppe tror jeg vil gjøre dem alle…).
Disse 26 kan deles inn i 3 typer:
1. Creational: Disse mønstrene er designet for klasse oppretting. De kan enten være klasse-etablering mønstre eller objekt-creational mønstre.
2. Strukturell: Disse mønstrene er designet med hensyn til en klasse er struktur og sammensetning., Det viktigste målet for de fleste av disse mønstrene er å øke funksjonaliteten av klassen(e) som er involvert, uten å endre mye av sin sammensetning.
3. Atferdsmessige: Disse mønstrene er designet avhengig av hvordan en i klassen kommuniserer med andre.
I dette innlegget, vi vil gå gjennom en grunnleggende design mønster for hver klassifisert type.
Type 1: Creational – The Singleton Design Mønster
The Singleton Design er et Mønster som er Creational mønster, hvis mål er å opprette bare én forekomst av en klasse, og til å gi bare én global tilgangspunkt at objektet., Et ofte brukt eksempel på en klasse i Java er Kalender, der du kan ikke lage en instans av klassen. Den bruker også sin egen getInstance()metode for å få objektet til å bli brukt.
En klasse med singleton design mønster vil inkludere,
- En privat statisk variabel, holder den eneste instans av klassen.
- En privat konstruktør, så det kan ikke bli lagt et annet sted.
- En offentlig statisk metode, til å returnere enkelt forekomst av klassen.,
Det er mange forskjellige implementasjoner av singleton design. I dag, jeg vil gå gjennom implementeringer av;
1. Ivrige etter Oppretting
2. Lat Oppretting
3. Tråd-safe Oppretting
Ivrig Bever
public class EagerSingleton {// create an instance of the class.private static EagerSingleton instance = new EagerSingleton();// private constructor, so it cannot be instantiated outside this class.private EagerSingleton() { }// get the only instance of the object created.public static EagerSingleton getInstance() {return instance;}}Denne typen oppretting skjer under klasse lasting, som oppretting av variabel forekomst som skjer utenfor enhver metode. Dette utgjør en heftig ulempe hvis denne klasse ikke blir brukt i det hele tatt av klientprogrammet. Handlingsplanen, hvis denne klasse ikke blir brukt, er Lat Oppretting.,
Late Dager
Det er ikke mye forskjell fra de ovennevnte gjennomføring. De viktigste forskjellene er at den statiske variabelen er i utgangspunktet kjennes, og er bare lagt innenfor getInstance() metoden hvis – og bare hvis – instance variable er fortsatt null på tidspunktet for sjekk.
Dette løser ett problem, men en annen en fortsatt eksisterer. Hva om to forskjellige klienter få tilgang til Singleton klasse på samme tid, rett til millisekund?, Vel, de vil undersøke om forekomsten er null på samme tid, og vil finne det sanne, og så vil opprette to forekomster av klassen for hver forespørsel av to klienter. For å fikse dette, Tråd-Safe oppretting er å bli implementert.
(Tråden) Sikkerhet er Nøkkelen
I Java, søkeordet synkronisert brukes på metoder eller objekter for å implementere tråden sikkerhet, slik at bare en tråd vil få tilgang til en bestemt ressurs på en gang. Klassen oppretting er satt inn i en synkronisert blokk, slik at metoden kan bare nås ved en klient på et gitt tidspunkt.,
overhead for synkronisert metode er høy, og reduserer ytelsen til hele operasjonen.
For eksempel, hvis instance variable har allerede blitt instansiert, så hver gang noen klienten får tilgang til getInstance() metode, synchronized metode er å kjøre, og ytelsen synker. Dette bare skjer for å sjekke om instance variabler’ – verdien er null. Hvis den finner at det er, det etterlater metoden.
for Å redusere dette overhead, dobbel låsing er brukt., Kontrollen er brukt før synchronized metode som er godt, og hvis verdien er null alene, gjør det synchronized metode kjøre.
Nå til neste klassifisering.
Type 2: Strukturell – Det Dekoratør Design Mønster
jeg skal gi deg et lite scenario for å gi en bedre sammenheng, hvorfor og hvor du skal bruke Decorator Pattern.
Si at du eier en kaffebar, og som en hvilken som helst nybegynner, du starter med bare to typer av vanlig kaffe, huset blanding og dark roast., I fakturerings-system, var det en i klassen for de ulike kaffeblandinger, som arver drikke abstrakt klasse. Folk faktisk begynner å komme med, og har fantastisk (om enn bitter?) kaffe. Så er det kaffe newbs at, Gud forby, vil sukker eller melk. Slik en parodi, for kaffe!! ??
Nå må du ha disse to add-ons, så vel, både til menyen og dessverre på fakturering system. Opprinnelig, IT-person vil gjøre en subclass for både kaffe, en inkludert, sukker, melk., Så, siden kundene er alltid rett, man sier at disse fryktede ord:
«Kan jeg få en melk, kaffe, sukker, er du snill?»
???
Det går fakturering system ler i ansiktet igjen. Vel, tilbake til tegnebrettet….
DEN personen deretter legger melk kaffe med sukker som en annen underklassen til hver av foreldrene kaffe klasse. Resten av måneden er jevn seiling, folk i kø for å få kaffe, du faktisk tjene penger. ??
Men vent, det er mer!
verden er mot deg igjen., En konkurrent åpner opp over gaten, med ikke bare 4 typer kaffe, men mer enn 10 add-ons, så vel! ?
Du kjøpe alle disse og mer, for å selge bedre kaffe selv, og bare så husk at du glemte å oppdatere dratted fakturering system. Du ganske muligens ikke kan gjøre uendelig antall av underklasser for alle, og alle kombinasjoner av alle add-ons, med den nye kaffeblandinger også. For ikke å nevne, størrelsen av det endelige systemet.??
Tid til å faktisk investere i en skikkelig fakturering system., Du finner nye IT-personell, som faktisk vet hva de driver med, og de sier;
«Hvorfor, denne vil bli så mye enklere og mindre hvis det brukes decorator pattern.»
Hva i all verden er det?
dekoratør design mønster som faller inn strukturell kategori, som omhandler den faktiske strukturen i en klasse, enten ved arv, sammensetning eller begge deler. Målet med denne konstruksjonen er å endre en objekter’ funksjonalitet ved kjøring. Dette er en av de mange andre design mønstre som benytter abstrakte klasser og grensesnitt med komposisjon for å få ønsket resultat.,
La oss gi Matematikk en sjanse (grøss?) for å få alt dette i perspektiv;
Ta 4 kaffeblandinger og 10 add-ons. Hvis vi stakk til generering av underklasser for hver enkelt kombinasjon av alle add-ons for en type kaffe. Det er;
(10-1)2 = 92 = 81 underklasser
Vi trekker fra 1 til 10, så kan du ikke kombinere en add-on med en annen av samme type, sukker, sukker høres dumt. Og det er bare for en kaffe blanding. Multipliser at 81 av 4, og du får en heidundrende 324 ulike underklasser!, Snakk om alt som koding…
Men med decorator pattern vil kreve bare 16 klasser i dette scenariet. Ønsker du å satse?
Hvis vi kartlegge vårt scenario i henhold til klasse diagrammet ovenfor, vi får 4 klasser for 4 kaffeblandinger, 10 for hver add-on og 1 for abstrakt komponent, og 1 mer for abstrakte dekoratør. Se! 16!, Nå hånd over $100.?? (jk, men det vil ikke bli nektet hvis gitt… bare å si)
Som du kan se fra oven, akkurat som betong kaffeblandinger er underklasser av drikke abstrakt klasse, det AddOn abstrakt klasse også arver sine metoder fra det. Add-ons, som er dens underklasser, i sin tur arve alle nye metoder for å legge til funksjonalitet for å base objekt når det er nødvendig.
La oss få til koding, for å se dette mønsteret er i bruk.,
Første til å gjøre det Abstrakte drikke klasse, som alle de forskjellige kaffeblandinger vil arve fra:
Klikk for å legge til både konkrete kaffe blanding klasser.
– Den AddOn abstrakt klasse også arver fra Drikke abstrakt klasse (mer om dette nedenfor).
Og nå konkrete implementasjoner av denne abstrakte klassen:
Som du kan se ovenfor, kan vi passere noen underklassen av Drikke til alle underklassen av AddOn, og få ekstra kostnad samt oppdatert beskrivelse. Og, siden add-on klasse i hovedsak er av typen Drikke, kan vi passere en AddOn til en annen AddOn., På denne måten kan vi legge til en rekke add-ons til en bestemt kaffe blanding.
Nå til å skrive noen kode for å teste dette ut.
Det endelige resultatet er:
Det fungerer! Vi var i stand til å legge til mer enn én add-on til en kaffe blanding og har oppdatert sin endelige kostnadene og beskrivelse, uten at du trenger å gjøre uendelig underklasser for hver add-on kombinasjon for alle kaffeblandinger.
til Slutt, til den siste kategorien.,
– Type 3: Atferdsmessige – Kommandoen Design Mønster
En atferdsmessige design mønster fokuserer på hvordan klasser og objekter kommunisere med hverandre. Hovedfokus for kommando-mønster er å innebære en høyere grad av løs kopling mellom de berørte parter (les: klasser).
Uhhhh… Hva er det?
Kopling er slik at to (eller flere) klasser som samhandler med hverandre, vel, samhandle. Det ideelle scenario når disse klassene samhandle er at de ikke er avhengige tungt på hverandre. Det er løs kopling., Så, en bedre definisjon for løs kopling ville være, klasser som er knyttet sammen, noe som gjør den minst bruken av hverandre.
behovet for dette mønsteret oppsto da forespørsler trengs for å bli sendt uten bevisst å vite hva du ber om eller hvem mottakeren er.
I dette mønsteret, det viste klasse er frakoblet fra klassen som faktisk utfører en handling. Den invoker klassen bare har callable metode utføre, som går nødvendig kommando, når kunden ber om det.
La oss ta et grunnleggende eksemplet fra den virkelige verden, bestille et måltid på en fancy restaurant., Så går strømmen, du gir din bestilling (kommando) til kelneren (invoker), som deretter hender det over til kokken(mottaker), så du kan få mat. Høres kanskje enkelt… men litt meh kode.
ideen er ganske enkel, men det koding går rundt nesen.,
flyten av drift på den tekniske siden er, du gjør en betong-kommandoen, som implementerer Kommando-grensesnitt, ber mottakeren for å fullføre en handling, og sende kommandoen til invoker. Den invoker er den person som vet når å gi denne kommandoen. Kjøkkensjefen er den eneste som vet hva de skal gjøre når de får bestemt kommando/bestilling., Så, når execute-metode til invoker kjøres, vil det i sin tur fører til at kommandoen objekter’ execute-metode til å kjøre på mottakeren, og dermed at nødvendige handlinger.,
Hva vi trenger for å implementere er;
- Et grensesnitt Kommandoen
- En klasse For at implementerer Kommando-grensesnitt
- En klasse Servitør (invoker)
- En klasse Kokk (mottaker)
Så, koding går som dette:
Kokk, mottakeren
– Kommandoen, grensesnittet
public interface Command {public abstract void execute();}Ordre, betong-kommandoen
Servitør, den invoker
public class Waiter {private Order order;public Waiter(Order ord) {this.order = ord;}public void execute() {this.order.execute();}}Du, klienten
Som du kan se ovenfor, Klienten gjør en Bestilling og setter Mottakeren som Kokk., Ordren er sendt til Kelneren, som vil vite når du skal utføre Ordre (dvs. når du skal gi kokk for å lage mat). Når invoker er utført, Bestillinger’ execute-metode er å kjøre på mottakeren (dvs. kokken er gitt kommandoen for å enten lage pasta ? eller bake kake?).,
Rask oppsummering
I dette innlegget, gikk vi gjennom:
- Hva et design mønster egentlig er,
- De forskjellige typer av design patterns og hvorfor de er forskjellige
- En grunnleggende eller vanlige design mønster for hver type
jeg håper dette var nyttig.
Finne den koden repo for innlegget, her.