Designmønstre i Java [Del 1]

Dette er en kort artikkel om designmønstre i Java. Det vil ikke være noen mønsterimplementeringer, bare en liste over mønstre i Java sammen med en kort beskrivelse av hver. For de som allerede er kjent med emnet, vil dette være nyttig som en gjennomgang og oppsummering. Motsatt vil de som lærer om mønstre for første gang ha nytte av dette som en innledende oversikt over temaet før de graver dypere. Design mønstreer klare til bruk løsninger for ofte forekommende programmeringsoppgaver. Det er ikke en klasse eller et bibliotek som kan kobles til et prosjekt. Det er noe mer. Designmønstre som passer for hver oppgave implementeres i hvert enkelt tilfelle. Du bør huske at når det brukes feil eller på en uegnet oppgave, kan et designmønster skape mange problemer. Imidlertid kan et riktig brukt mønster hjelpe deg med å fullføre oppgaver enkelt og enkelt.

Typer mønstre:

• skapende
• strukturell
• atferdsmessige

Kreasjonsmønstre gir initialiseringsmekanismer, slik at du kan lage objekter på praktiske måter. Strukturelle mønstre definerer forhold mellom klasser og objekter, slik at de kan jobbe sammen. Atferdsmønstre brukes for å forenkle interaksjon mellom enheter.

Kreasjon:

• Singleton — begrenser opprettelsen av en klasse til en enkelt forekomst, og gir tilgang til den enkelt forekomsten.

• Factory — brukes når vi har en superklasse med flere underklasser og vi må returnere en underklasse basert på input.

• Abstrakt fabrikk — bruker en superfabrikk til å lage fabrikker, som vi deretter bruker til å lage objekter.

• Builder - brukes til å lage komplekse objekter ved hjelp av enkle objekter. Den skaper gradvis en stor gjenstand fra en liten, enkel gjenstand.

• Prototype – bidrar til å forbedre ytelsen når du oppretter dupliserte objekter; i stedet for å lage et nytt objekt, oppretter og returnerer det en klone av et eksisterende objekt.

Strukturell:

• Adapter — en omformer mellom to inkompatible objekter. Vi kan bruke adaptermønsteret til å kombinere to inkompatible grensesnitt.

• Composite — bruker én klasse for å representere en trestruktur.

• Proxy — gir funksjonaliteten til en annen klasse.

• Flyweight — gjenbruker objekter i stedet for å lage et stort antall lignende objekter.

• Fasade — gir et enkelt grensesnitt for en klient, som bruker grensesnittet til å samhandle med systemet.

• Bridge — gjør spesifikke klasser uavhengige av klasser som implementerer et grensesnitt.

• Dekorator – legger til ny funksjonalitet til et eksisterende objekt uten å knytte seg til strukturen.

Atferdsmessig:

• Malmetode — definerer en grunnleggende algoritme og lar etterkommere overstyre noen trinn i algoritmen uten å endre dens generelle struktur.

• Mediator – gir en mellomklasse som håndterer all kommunikasjon mellom ulike klasser.

• Ansvarskjede — gjør det mulig å unngå streng avhengighet mellom avsender og mottaker av en forespørsel; dessuten kan forespørselen behandles av flere objekter.

• Observer — lar ett objekt overvåke og reagere på hendelser som skjer i andre objekter.

• Strategi — gjør det mulig å endre strategier (algoritmer) under kjøring.

• Kommando - et grensesnitt som erklærer en metode for å utføre en spesifikk handling.

• Tilstand — lar et objekt endre sin oppførsel avhengig av tilstanden.

• Besøkende – brukes til å forenkle operasjoner på grupper av relaterte objekter.

• Tolk — definerer en grammatikk for et enkelt språk i problemdomenet.

• Iterator – får sekvensielt tilgang til elementer i en samling uten å vite dens underliggende form.

• Memento — brukes til å lagre et objekts tilstand; denne tilstanden kan gjenopprettes senere.

Når du går gjennom CodeGym-kurset, vil du møte et par mønstre på denne listen. Jeg anbefaler følgende oppgaver om mønstre: 1522 , 1530 , 1631 , big01 , 2912 , 3107 ... Klok bruk av designmønstre fører til mer pålitelig kodevedlikehold, fordi, i tillegg til at designmønstre er gode løsninger på vanlige problemer , kan andre utviklere gjenkjenne dem, noe som reduserer tiden det tar å jobbe med bestemt kode.