Het ontwerppatroon van de waarnemer lijkt op een podcast

Als je naar podcasts luistert, ben je al bekend met het Observer-patroon. In feite ben je een "waarnemer".

Hier is de definitie voor het waarnemerspatroon:

Het waarnemerspatroon definieert een één-op-veel-afhankelijkheid tussen objecten, zodat wanneer een object van status verandert, alle afhankelijke personen op de hoogte worden gebracht en automatisch worden bijgewerkt.

Laten we de definitie bekijken die gerelateerd is aan podcasts.

Ik vond een interessante podcast met de naam ontwikkelaarsthee.

Nadat ik op de knop INSCHRIJVEN heb geklikt, sta ik nu in hun lijst met abonnees.

Wanneer ontwikkelaarsthee een nieuwe aflevering uitbrengt, stelt de app mij en andere abonnees op de hoogte. Het downloadt de nieuwe aflevering voor ons.

Dat is precies de definitie van het waarnemerspatroon!

Het waarnemerspatroon definieert een één-op-veel afhankelijkheid tussen objecten, zodat wanneer een object van status verandert, alle afhankelijke personen op de hoogte worden gebracht en automatisch worden bijgewerkt.

Er is een één-op-veel-relatie tussen de theepodcast van de ontwikkelaar en abonnees.

Wanneer ontwikkelaarsthee van status verandert, zoals het uitbrengen van een nieuwe aflevering, worden alle abonnees van ontwikkelaarsthee op de hoogte gebracht en bijgewerkt.

Laten we het in Ruby implementeren.

Begin met een eenvoudige versie.

De klasse Podcast bevat een lijst met afleveringen en heeft een methode om een ​​aflevering toe te voegen aan de lijst.

Vervolgens kunnen we de ontwikkelaar_tea podcast maken en aflevering 1 als volgt toevoegen:

Ik wil een melding ontvangen wanneer een nieuwe aflevering wordt uitgebracht.

We kunnen me updaten nadat we een nieuwe aflevering aan de lijst hebben toegevoegd:

En wanneer ik een update krijg van developer_tea, kan ik doorgaan en de nieuwste aflevering downloaden.

Ik luister zo graag naar developer_tea dat ik het aan mijn vriend Amber aanbeveel. Nu wil Amber zich er ook op abonneren.

We moeten ervoor zorgen dat Amber ook een melding ontvangt wanneer een nieuwe aflevering wordt uitgebracht:

Hmmm, deze code doet wat we willen.

Maar er is een probleem.

Elke keer dat we een abonnee willen toevoegen, moeten we de klasse opnieuw definiëren.

Is er een manier om de deelnemerslijst bij te werken zonder de klasse opnieuw te moeten definiëren?

We kunnen een deelnemerslijst bijhouden!

De nieuwe Podcast-klasse houdt een abonneelijst bij met behulp van twee nieuwe methoden: een voor het toevoegen van abonnees en een voor het verwijderen van abonnees. Wanneer een aflevering wordt vrijgegeven, werken we elke abonnee bij.

Helaas geniet Amber niet zoveel van de podcast als ik en besluit hij zich af te melden. We gebruiken de methode remove_subscriber om haar uit de lijst met abonnees te verwijderen.

Yay! Je hebt zojuist het waarnemerspatroon geleerd!

Ontwerpprincipe achter het waarnemerspatroon.

Het waarnemerspatroon maakt gebruik van het ontwerpprincipe van de losse koppeling:

Streef naar losjes gekoppelde ontwerpen tussen objecten die op elkaar inwerken.

De Podcast-klasse weet niet veel over zijn abonnees. Het weet alleen dat elke abonnee een updatemethode heeft.

Deze losse koppeling minimaliseert de afhankelijkheid tussen Podcast en zijn abonnees. Het maximaliseert ook de flexibiliteit. Zolang het een updatemethode heeft, kan een abonnee van alles zijn: een mens, een groep mensen, een dier of zelfs een auto.

Takeaways:

  1. Het waarnemerspatroon definieert een één-op-veel afhankelijkheid tussen objecten, zodat wanneer een object van status verandert, alle afhankelijke personen op de hoogte worden gebracht en automatisch worden bijgewerkt.
  2. Ontwerpprincipe van losse koppeling: streef naar losjes gekoppelde ontwerpen tussen objecten die op elkaar inwerken.

Bedankt voor het lezen. Zijn er nog andere echte voorbeelden van het Observer-patroon die je kunt bedenken?

Ik publiceer wekelijks op sihui.io.

Abonneer je zodat je het volgende artikel uit de serie niet mist.

Volgende keer zullen we het hebben over ...