Design della classe per chiamare "lo stesso metodo" su classi diverse da un posto

Dovresti prendere seriamente in considerazione l'utilizzo del modello di osservatore e, piuttosto che chiamare un metodo di aggiornamento che itera attraverso un elenco di oggetti che necessita di un aggiornamento, chiami semplicemente un evento a cui tutti gli oggetti sono iscritti finché sono validi per essere aggiornati?

Mentre potresti essere tentato di creare una classe astratta o un'interfaccia. Vorrei strongmente sconsigliare questo approccio.

Motivi contro le interfacce

1. Finirai con due classi che svolgono lo stesso lavoro.
2. Definisce un contratto ma non migliora la coesione del codice.

Ragioni contro l'astrazione

1. Finirai con 3 lezioni. La classe base e 2 classi di implementazione.
2. La maggior parte dei metodi astratti sarà pubblica. L'astrazione funziona al meglio quando l'ambito dei metodi riutilizzati è protetto. Questo rende chiaro che la classe astratta è veramente lì per aiutare le classi ereditate.

Approccio consigliato

1. Definisci una classe cache sigillata a cui non importa quando si memorizza nella cache. Crea una classe chiamata DatabaseCacher che sappia come mantenere ICachable oggetti in memoria.
2. Articles e Categories quindi implementa l'interfaccia ICachable .

DatabaseCacher dovrebbe essere usato per modificare le proprietà di ICachable . Non implementare metodi di setter sugli oggetti ICachable . Invece, crea un metodo setter generico su DatabaseCacher che prende il nome della proprietà come parametro con il suo valore. Ciò consente di localizzare tutte le operazioni di caching e scrittura di tali oggetti.

Eviterei di usare un approccio di ascolto degli eventi di modifica delle proprietà. Poiché crea un numero elevato di rilegature tra solo due entità ( DatabaseCacher e ICachable oggetti). Gli ascoltatori di modifiche alle proprietà funzionano meglio quando la connessione è ambigua.