Designmønstre i Java Hva er de og hva består de av?

Vil du vite hva som er designmønstre i Java? Du kom til den riktige artikkelen, for her vil vi fortelle deg hva de er, så vel som vi vil fortelle deg klassifiseringen og litt mer.

design-mønstre-i-java-1

Objektdiagram for å løse generiske problemer.

Design mønstre i Java

Før du snakker om designmønstre i Java, må vi merke oss at disse er fokusert mot objektorientert programmering. For det andre er det viktig å huske noen tilhørende grunnleggende, inkludert følgende:

For ytterligere informasjon, inviterer vi deg til å lese artikkelen vår: The Objektorientert programmering: Definisjon.

Tilhørende grunnleggende

Som vi alltid har sagt, er programmering ikke en isolert hendelse, så det er alltid viktig å huske noen relaterte begreper. Ved denne anledningen er det nok å referere til følgende aspekter:

Java-programmeringsspråk

Java er et av de eldste dataprogrammeringsspråkene; det er også i populær bruk på de fleste plattformer. I denne forbindelse kan vi nevne at mange av dataprogrammene vi har i dag er basert på dette viktige språket.

På dette siste aspektet kan vi først og fremst nevne applikasjonene knyttet til webtjenester. For eksempel: mobilapplikasjoner, skrivebord, servere, blant andre.

På den annen side tilhører Java det objektorienterte programmeringsparadigmet. I denne forbindelse, til tross for dens natur, regnes det som et pålitelig, trygt og brukervennlig språk.

I tillegg har den fordelen av å kunne kjøre på hvilken som helst virtuell Java -maskin, uavhengig av datamaskinarkitekturen. Med andre ord, Java er et bærbart programmeringsspråk.

design-mønstre-i-java-2

Design mønster

Et designmønster er en løsning på et designproblem, som ofte forekommer i objektorientert programmering. I tillegg inneholder dette diagrammet beskrivelsen av objektene etter klasser, så vel som forholdene som forbinder dem.

På den annen side er det viktig å nevne at designmønstre generelt er et resultat av tidligere erfaringer fra programmerere. I tillegg er det ingen teoretisering i designmønstrene i Java, slik det skjer med andre programmeringselementer, for eksempel; algoritmer.

Hva er designmønstre i Java?

Som vi allerede har nevnt, er et designmønster et objektdiagram som oppfyller formålet med å løse et programmeringsproblem. Nå er designmønstre i Java de representerer løsningen på problemet, nedfelt i et program skrevet på dette spesifikke programmeringsspråket.

Hva er designmønstrene i Java?

Generelt kan vi snakke om 23 designmønstre i Java. I denne forbindelse ble disse avslørt for første gang i 1995, gjennom boken Dessing Patterns.

På den annen side, som vi allerede har sagt, er disse mønstrene avgjørende for å løse mulige nye problemer. I tillegg er de svar på kjente problemer, som stammer fra tidligere erfaringer fra programmerere som er spesialisert på det objektorienterte paradigmet.

Typer designmønstre i Java

Generelt er hvert av de 23 grunnleggende designmønstrene kategorisert i en av de tre generelle typene designmønstre i Java som eksisterer. På denne måten vil vi nedenfor vise detaljene om hver av dem.

design-mønstre-i-java-3

Konstruksjonsmønstre

Hovedfunksjonen til konstruksjonsmønstre er å organisere opprettelsen av objekter, innkapsling av bruk av betongklasser og fremme grensesnittene i forholdet mellom dem. Til denne klassen av mønstre hører følgende:

Abstrakt fabrikk

Den er ansvarlig for å lage objekter gruppert som en familie, uten å ta hensyn til de spesifikke klassene som objektene dannes gjennom.

Builder

Det gir muligheten til å lage komplekse objekter uansett implementering eller med andre ord gjennom forskjellige implementeringer.

Fabrikkmetode

Hovedfunksjonen til dette mønsteret er å delegere opprettelsen av et objekt til bestemte underklasser. I denne forbindelse oppnås dette ved bruk av en abstrakt metode.

Prototype

Det letter opprettelsen av nye objekter fra prototyper fra duplisering eller kloning av eksisterende objekter.

Singleton

Funksjonen til dette mønsteret er å administrere eksistensen av klasser som bare har en forekomst, samt å tilby en metode som er i stand til å returnere nevnte forekomst.

I denne forbindelse kan du se mer informasjon i den følgende videoen.

Strukturmønstre

På sin side har strukturmønstrene ansvaret for å organisere hierarkiene til klassene og forholdene som fletter dem sammen. Innenfor denne klassifiseringen er følgende:

adapter

Det er ansvarlig for å transformere grensesnittet til en eksisterende klasse til et annet med de egenskapene ønsket av brukerne av systemet, på en slik måte at begge er kompatible. Kort sagt, adaptermønsteret er ansvarlig for å tilpasse et eksisterende objekt.

Bridge

Hovedfunksjonen til dette mønsteret er å løsne de konseptuelle aspektene som tilhører et klassehierarki fra implementeringen. Med andre ord er dette mønsteret ansvarlig for å implementere et objekt.

Kompositt

Denne typen mønster er ansvarlig for å generere en tredesignramme, som kommer fra en sammensetning av objekter med variabel dybde. Med andre ord er dette ansvarlig for å organisere den hierarkiske sammensetningen av objekter.

dekoratør

Den brukes til å legge til nye funksjoner, hovedsakelig dynamiske, til et objekt for å utfylle det. I denne forbindelse er resultatet av dette mønsteret erstatning av et eksisterende objekt.

Om dette mønsteret kan du få mer informasjon gjennom følgende video.

fasade

Hovedmålet er å lette bruken av et grensesnitt av objekter, slik at flere av dem grupperes og forenes til ett. Som i det forrige mønsteret, er sluttresultatet erstatning av en serie objekter.

Flyvekt

Generelt er Flayweight -mønsteret ansvarlig for delingsprosessen for en serie objekter, spesielt de som har ekstremt fin granularitet. I tillegg er det ansvarlig for å beholde en uavhengig tilstand av dem.

Proxy

Hovedfunksjonen til et proxy -mønster er å bygge et objekt som kan erstattes av et annet, som har full kontroll over tilgangen. I denne forbindelse er målet hovedsakelig å gi de ideelle forholdene når det gjelder optimalisering og beskyttelse av objektet.

Atferdsmønstre

Til slutt er atferdsmønstrene de som gir løsningene for å organisere dataene og objektene, i tillegg etablerer de rekkefølgen mellom interaksjonene som oppstår i sistnevnte. Innenfor denne gruppen av mønstre kan vi finne følgende:

Ansvarskjede

Som navnet antyder, refererer dette mønsteret til opprettelsen av en kjede med objekter, slik at når en av dem ikke kan svare på en instruksjon, kan den neste lenken gi den tilsvarende responsen.

Kommando

Hovedmålet med dette mønsteret er å konvertere en forespørsel til et objekt, på en slik måte at de relaterte grunnleggende operasjonene er lettere å utføre. Det vil si at dens funksjon er å transformere en forespørsel til et objekt.

Tolk

Det refererer til muligheten for å tilby representasjon av et språk gjennom grammatiske objekter. Dette for at de skriftlige uttrykkene for det språket enkelt kan evalueres og tolkes.

Hvis du vil ha mer informasjon om det, kan du se følgende video.

iterator

Hovedfunksjonen er å tillate sekvensiell tilgang til en gruppe objekter, uten at systembrukere trenger å kjenne aspektene knyttet til implementeringen.

Mellommann

Som navnet antyder, er dette mønsteret ansvarlig for å bygge et objekt som fungerer som en formidler mellom objektets interaksjon uten at de samhandler direkte.

Påminnelse

Generelt sett er det et av de viktigste mønstrene, siden det er han som har ansvaret for å gjenopprette og ivareta gjenstandenes tilstand. I denne forbindelse må vi merke at en grunnbetingelse i dette mønsteret er respekt for innkapslingen av klassene.

Observatør

Hovedfunksjonen til dette mønsteret er å varsle observatørene om endringene som har skjedd i motivet, slik at de kan oppdatere statusen deres.

Tilstand

Målet med dette mønsteret er ganske lett å forstå, siden det har ansvaret for å tilby et objekt muligheten til å endre sin oppførsel basert på dens interne tilstand.

Strategi

Det letter tilpasningen mellom atferden og algoritmene til et objekt, avhengig av eksistensen eller ikke av et spesifikt behov fra systemets side. I denne forbindelse bør interaksjonene mellom objektet og brukerne av systemet ikke endres under anvendelsen av dette mønsteret.

Malmetode

Dette mønsteret er ansvarlig for å lage den tilsvarende rapporten om stadiene som utgjør operasjonene til et objekt, som er beskrevet i underklassene. Med andre ord er det et spørsmål om å delegere noen stadier som utgjør operasjonene til et objekt til underklassene.

Visitor

Den er ansvarlig for konstruksjonen av en nødvendig operasjon relatert til elementene i en serie objekter, uten at det skjer noen endringer i deres klasser. Kort sagt, dette mønsteret er ansvarlig for å legge til nye operasjoner i en serie objekter.

Fordeler med layoutmønstre i Java

Generelt kan vi si at den største fordelen med designmønstre i Java er at de tillater å bygge komplekse og robuste applikasjoner. I tillegg gir den muligheten til å gjenbruke allerede kjente løsninger i utformingen av nye løsninger.

På den annen side, gjennom bruk av designmønstre i JavaDesignere og utviklere generelt kan styrke sin kunnskap om objektorientert programmering. I denne forbindelse kan vi blant hovedgrunnlaget for dette programmeringsparadigmet nevne følgende: polymorfisme, arv, innkapsling, blant andre.

Hvordan gjenkjenne hvilket designmønster som passer vårt problem?

For å identifisere hvilket designmønster i Java som er det som svarer best på et spesifikt programmeringsproblem, er det første vi må vite målet. På denne måten, når vi har studert den generelle beskrivelsen av hvert designmønster, er det neste å gå videre til tilpasningstrinnet.

I denne forbindelse refererer det til muligheten for at mønsterets generiske struktur tilpasser seg vårt problem. For å gjøre dette omdøper vi klassene og metodene til strukturen og integrerer dem i applikasjonen vår på en abstrakt måte, for å teste om mønsteret faktisk er i stand til å svare på våre krav.

Til slutt, hvis vi er på rett spor, er det siste trinnet å navngi disse klassene og metodene i henhold til objektet de beskriver og operasjonene de utfører. I denne forbindelse er det viktig å merke seg at det i noen tilfeller er nødvendig å gjøre endringer i objektdiagrammet.