Observer Design Pattern er på samme måte som en podcast

Hvis du hører på podcaster, er du allerede kjent med Observer-mønsteret. Faktisk er du en "observatør".

Her er definisjonen for observatørmønsteret:

Observatormønsteret definerer en en-til-mange-avhengighet mellom objekter slik at når ett objekt endrer tilstand, blir alle avhengige varslet og oppdatert automatisk.

La oss se på definisjonen som er relatert til podcaster.

Jeg fant en interessant podcast som heter Developer tea.

Etter å ha klikket på SUBSCRIBE-knappen, er jeg nå på abonnentlisten deres.

Når utvikler te slipper en ny episode, vil appen varsle meg og andre abonnenter. Den laster ned den nye episoden for oss.

Det er nøyaktig definisjonen av observatørmønsteret!

Observatormønsteret definerer en en-til-mange-avhengighet mellom objekter slik at når ett objekt endrer tilstand, blir alle avhengige varslet og oppdatert automatisk.

Det er et en-til-mange forhold mellom utvikleren te podcast og abonnenter.

Når utviklerte endrer tilstand, for eksempel å slippe en ny episode, blir alle abonnentene på utviklerte varslet og oppdatert.

La oss implementere det i Ruby.

Begynn med en enkel versjon.

Podcast-klassen har en liste over episoder og har en metode for å legge til_episode til listen.

Så kan vi lage utvikleren-podcasten og legge til episode 1 slik:

Jeg ønsker å få et varsel hver gang en ny episode slippes.

Vi kan oppdatere meg etter å ha lagt til en ny episode på listen:

Og når jeg får en oppdatering fra Developer_tea, kan jeg gå videre og laste ned den siste episoden.

Jeg liker å høre på Developer_tea så mye at jeg anbefaler det til min venn, Amber. Nå ønsker Amber å abonnere på det også.

Vi må sørge for at Amber også får et varsel hver gang en ny episode slippes:

Hmmm, denne koden gjør det vi vil.

Men det er et problem.

Hver gang vi vil legge til en abonnent, må vi omdefinere klassen.

Er det en måte å oppdatere abonnentlisten uten å måtte omdefinere klassen?

Vi kan føre en abonnentliste!

Den nye Podcast-klassen fører en abonnentliste ved hjelp av to nye metoder: en for å legge til abonnenter og en for å fjerne abonnenter. Når en episode slippes, oppdaterer vi hver abonnent.

Dessverre liker ikke Amber podcasten så mye som jeg, og bestemmer seg for å melde seg ut. Vi bruker remove_subscribber-metoden for å fjerne henne fra abonnentlisten.

Yay! Du har nettopp lært observatormønsteret!

Designprinsipp bak Observer-mønsteret.

Observer-mønsteret bruker Loose Coupling designprinsippet:

Tilstrebe løst koblede design mellom objekter som samhandler.

Podcast-klassen vet ikke så mye om abonnentene sine. Den vet bare at hver abonnent har en oppdateringsmetode.

Denne løse koblingen minimerer avhengigheten mellom Podcast og dets abonnenter. Det maksimerer også fleksibiliteten. Så lenge den har en oppdateringsmetode, kan en abonnent være hva som helst: et menneske, en gruppe mennesker, et dyr eller til og med en bil.

takeaways:

  1. Observatormønsteret definerer en en-til-mange-avhengighet mellom objekter slik at når ett objekt endrer tilstand, blir alle avhengige varslet og oppdatert automatisk.
  2. Loose Coupling designprinsipp: strebe etter løst koblede design mellom gjenstander som samvirker.

Takk for at du leste. Er det noen andre virkelige eksempler på observatormønsteret du kan tenke på?

Jeg publiserer til sihui.io ukentlig.

Abonner slik at du ikke går glipp av den neste artikkelen fra serien.

Neste gang skal vi snakke om ...