Il modello di progettazione Observer è un po 'come un podcast

Se ascolti i podcast, hai già familiarità con il modello Observer. In realtà, sei un "osservatore".

Ecco la definizione per il modello Observer:

Il modello Observer definisce una dipendenza uno-a-molti tra gli oggetti in modo che quando un oggetto cambia stato, tutti i suoi dipendenti vengono notificati e aggiornati automaticamente.

Diamo un'occhiata alla definizione in relazione ai podcast.

Ho trovato un podcast interessante chiamato tè per sviluppatori.

Dopo aver fatto clic sul pulsante ISCRIVITI, ora sono sul loro elenco di iscritti.

Quando il tè dello sviluppatore pubblica un nuovo episodio, l'app avviserà me e altri abbonati. Scarica il nuovo episodio per noi.

Questa è esattamente la definizione del modello Observer!

Il modello Observer definisce una dipendenza uno-a-molti tra gli oggetti in modo che quando un oggetto cambia stato, tutti i suoi dipendenti vengono notificati e aggiornati automaticamente.

Esiste una relazione uno-a-molti tra il podcast dello sviluppatore e gli abbonati.

Quando cambia lo stato del tè dello sviluppatore, come il rilascio di un nuovo episodio, tutti gli abbonati del tè dello sviluppatore vengono avvisati e aggiornati.

Implementiamolo in Ruby.

Inizia con una versione semplice.

La classe Podcast contiene un elenco di episodi e ha un metodo per aggiungere_codice all'elenco.

Quindi possiamo creare il podcast developer_tea e aggiungere l'episodio n. 1 in questo modo:

Voglio ricevere una notifica ogni volta che viene rilasciato un nuovo episodio.

Possiamo aggiornarmi dopo aver aggiunto un nuovo episodio all'elenco:

E ogni volta che ricevo un aggiornamento da developer_tea, posso andare avanti e scaricare l'ultimo episodio.

Mi piace ascoltare developer_tea così tanto che lo consiglio a Amber, la mia amica. Ora, anche Amber vuole iscriversi.

Dobbiamo assicurarci che anche Amber riceva una notifica ogni volta che viene rilasciato un nuovo episodio:

Hmmm, questo codice fa quello che vogliamo.

Ma c'è un problema.

Ogni volta che vogliamo aggiungere un abbonato, dobbiamo ridefinire la classe.

Esiste un modo per aggiornare l'elenco degli iscritti senza dover ridefinire la classe?

Possiamo tenere un elenco di iscritti!

La nuova classe Podcast mantiene un elenco di abbonati con l'aiuto di due nuovi metodi: uno per aggiungere abbonati e uno per rimuovere abbonati. Quando viene rilasciato un episodio, aggiorniamo ogni abbonato.

Sfortunatamente, Amber non ama il podcast quanto me e decide di annullare l'iscrizione. Usiamo il metodo remove_subscriber per rimuoverla dall'elenco degli iscritti.

Yay! Hai appena imparato il modello Observer!

Principio di progettazione alla base del modello Observer.

Il modello Observer utilizza il principio di progettazione dell'accoppiamento libero:

Sforzati di realizzare progetti liberamente accoppiati tra oggetti che interagiscono.

La classe Podcast non sa molto dei suoi iscritti. Sa solo che ogni abbonato ha un metodo di aggiornamento.

Questo accoppiamento libero riduce al minimo la dipendenza tra Podcast e i suoi abbonati. Massimizza anche la flessibilità. Finché ha un metodo di aggiornamento, un abbonato può essere qualsiasi cosa: un essere umano, un gruppo di persone, un animale o persino un'auto.

asporto:

  1. Il modello Observer definisce una dipendenza uno-a-molti tra gli oggetti in modo che quando un oggetto cambia stato, tutti i suoi dipendenti vengono notificati e aggiornati automaticamente.
  2. Principio di progettazione di accoppiamento libero: cerca di progettare liberamente accoppiati tra oggetti che interagiscono.

Grazie per aver letto. Ci sono altri esempi di vita reale del modello Observer a cui puoi pensare?

Pubblico su sihui.io settimanalmente.

Iscriviti in modo da non perdere il prossimo articolo della serie.

La prossima volta parleremo di ...