Observer Design Pattern on kuin podcast

Jos kuuntelet podcasteja, tunnet jo Observer-kuvion. Itse asiassa olet “tarkkailija”.

Tässä on tarkkailijamallin määritelmä:

Tarkkailijamalli määrittelee objektien välisen riippuvuussuhteen yhdestä toiseen niin, että kun yksi objekti muuttuu tilaan, kaikki sen riippuvaiset ilmoitetaan ja päivitetään automaattisesti.

Katsotaanpa määritelmää, joka liittyy podcasteihin.

Löysin mielenkiintoisen podcastin nimeltä kehittäjätee.

Napsautuksena VAKAAVA-painiketta olen nyt heidän tilaajaluettelossaan.

Kun kehittäjätee julkaisee uuden jakson, sovellus ilmoittaa minulle ja muille tilaajille. Se lataa uuden jakson meille.

Se on tarkalleen tarkkailijan kuvion määritelmä!

Tarkkailijamalli määrittelee objektien välisen riippuvuussuhteen yhdestä toiseen niin, että kun yksi objekti muuttuu tilaan, kaikki sen riippuvaiset ilmoitetaan ja päivitetään automaattisesti.

Kehittäjän tee-podcastin ja tilaajien välillä on suhde yksi-moniin.

Kun kehittäjätee muuttaa tilaa, kuten julkaisee uuden jakson, kaikille kehittäjäteeen tilaajille ilmoitetaan ja päivitetään.

Otetaan se käyttöön Rubyssa.

Aloita yksinkertaisella versiolla.

Podcast-luokka pitää luetteloa jaksoista ja sillä on menetelmä lisätä_episodi luetteloon.

Sitten voimme luoda developer_tea-podcastin ja lisätä siihen jakson 1 seuraavasti:

Haluan saada ilmoituksen aina kun uusi jakso julkaistaan.

Voimme päivittää minut lisättyäsi uuden jakson luetteloon:

Ja aina kun saan päivityksen developer_tealta, voin jatkaa ja ladata uusimman jakson.

Nautin kuuntelemasta developer_teaa niin paljon, että suosittelen sitä ystävälleni Amberille. Nyt Amber haluaa myös tilata sen.

Meidän on varmistettava, että Amber saa myös ilmoituksen, kun uusi jakso julkaistaan:

Hmmm, tämä koodi tekee mitä haluamme.

Mutta siinä on ongelma.

Joka kerta kun haluamme lisätä tilaajan, meidän on määriteltävä luokka uudelleen.

Onko tapa päivittää tilaajaluetteloa joutumatta määrittelemään luokkaa uudelleen?

"Voimme pitää tilaajaluetteloa!"

Uusi Podcast-luokka pitää tilaajaluetteloa kahden uuden menetelmän avulla: yksi tilaajien lisäämiseksi ja toinen tilaajien poistamiseksi. Kun jakso julkaistaan, päivitämme jokaisen tilaajan.

Valitettavasti Amber ei nautti podcastista yhtä paljon kuin minä ja päättää lopettaa tilauksen. Käytämme remove_subscriber -tapaa poistaaksemme hänet tilaajaluettelosta.

Yay! Olet juuri oppinut tarkkailijakuvion!

Tarkkailijakuvion takana oleva suunnittelupäätös.

Tarkkailijamallissa käytetään Loose Coupling -suunnitteluperiaatetta:

Pyrki löysästi kytkettyihin malleihin, jotka ovat vuorovaikutuksessa.

Podcast-luokka ei tiedä paljon tilaajistaan. Se vain tietää, että jokaisella tilaajalla on päivitysmenetelmä.

Tämä löysä kytkentä minimoi riippuvuuden Podcastin ja sen tilaajien välillä. Se maksimoi myös joustavuuden. Niin kauan kuin sillä on päivitysmenetelmä, tilaaja voi olla mikä tahansa: ihminen, ihmisryhmä, eläin tai jopa auto.

takeaways:

  1. Tarkkailijamalli määrittelee objektien välisen riippuvuussuhteen yhdestä toiseen niin, että kun yksi objekti muuttuu tilaan, kaikki sen riippuvaiset ilmoitetaan ja päivitetään automaattisesti.
  2. Löysän kytkennän suunnitteluperiaate: pyrkii löysästi kytkettyihin malleihin vuorovaikutuksessa olevien esineiden välillä.

Kiitos käsittelystä. Onko muita todellisen elämän esimerkkejä tarkkailijamallista, jota voit ajatella?

Julistan sihui.io: ​​lle viikossa.

Tilaa niin et menetä seuraavaa sarjan artikkelia.

Seuraavan kerran puhumme ...