Voglio un'alternativa di design a un singleton

Question

Mi rendo conto che c'è molta discussione sui singleton e sul perché sono cattivi. Non è di questa domanda. Comprendo gli svantaggi dei singleton.

Ho uno scenario in cui l'utilizzo di un singleton è semplice e sembra avere senso. Tuttavia, voglio un'alternativa che realizzerà ciò di cui ho bisogno senza un sovraccarico.

La nostra applicazione è progettata come un client che in genere viene eseguito su laptop sul campo e comunica con un server back-end. Abbiamo una barra di stato nella parte inferiore dell'applicazione principale. Contiene alcune aree di testo che mostrano varie statue e informazioni oltre a diverse icone. Le icone cambiano la loro immagine per indicare il loro stato. Come un'icona GPS che indica se è collegata o meno così come lo stato di errore.

La nostra classe principale si chiama MobileMain. Possiede l'area della barra di stato ed è responsabile della sua creazione. Abbiamo quindi una classe StatusBarManager. StatusBarManager è attualmente una classe statica, ma potrebbe anche essere un singleton. Ecco l'inizio della lezione.

public static class StatusBarManager 
{ 
    static ScreenStatusBar StatusBar; 

    /// <summary> 
    /// Creates the status bar that it manages and returns it. 
    /// </summary> 
    public static ScreenStatusBar CreateStatusBar() 
    { 
     StatusBar = new ScreenStatusBar(); 
     return StatusBar; 
    } 

Il MobileMain richiede StatusBarManager per StatusBar. Quindi utilizza StatusBar. Nessun'altra classe vede StatusBar, solo StatusBarManager.

Gli aggiornamenti alla barra di stato possono provenire praticamente da qualsiasi punto dell'applicazione. Ci sono circa 20 classi che possono aggiornare le aree di testo sulla barra di stato e classi aggiuntive che aggiornano gli stati delle icone.

Ci saranno solo uno StatusBar e un StatusBarManager.

Qualche suggerimento per una migliore implementazione?

Alcuni pensieri che ho avuto:

Fai lo StatusBarManager una classe di istanza. Nella mia classe MobileMain mantieni un'istanza pubblica statica della classe StatusBarManager. Quindi, per eseguire gli aggiornamenti della barra di stato, chiamare MobileMain.StatusBarManager.SetInformationText o qualche altro metodo del gestore. StatusBarManager non sarebbe un singleton, ma MobileMain creerebbe solo un'istanza statica di esso. Il problema qui è che MobileMain ora ha StatusBar e StatusBarManager, che gestisce solo lo StatusBar di sua proprietà. È inoltre disponibile un'istanza statica disponibile a livello globale per StatusBarManager, solo un proprietario diverso.

Un'altra idea era usare qualcosa come una classe EventEggregator. Non ne ho mai usato uno, ma ho letto su di loro. Immagino che il concetto sia che sarebbe una classe globalmente disponibile. In ogni classe che desidera aggiornare la barra di stato pubblicherà un evento StatusBarUpdate. StatusBarManager sarebbe l'unica classe che si iscrive all'evento StatusBarUpdate e riceverà tutte le notifiche. Ho letto però che può finire con perdite con questo approccio se non si presta attenzione a cancellarsi dagli eventi durante la pulizia degli oggetti. Questo approccio vale la pena esaminare?

Answer 1

Avere una classe StatusBar o una classe StatusBarManager o meno non è un grosso problema. Ma avere molte classi nella tua app a conoscenza di StatusBars e StatusBarManagers è una cattiva idea, causerà un forte accoppiamento, e un giorno probabilmente il dolore.

Come?

Immaginate che i componenti che attualmente segnalano lo stato di una barra di stato debbano essere riutilizzati in un'altra app che - utilizza una console di testo per riportare lo stato? - segnala lo stato a più posti? o - non segnala lo stato!

Migliore alternativa: -Evento di ascolto. Esporre un evento Status Changed sulla tua classe (puoi usare una callback), o forse su una risorsa condivisa esistente che le tue classi hanno in comune. Altre parti, come la barra di stato, possono iscriversi all'evento. E dovrebbe annullare l'iscrizione ogni volta che l'abbonamento non è più necessario/valido, per evitare perdite, come si menziona!

-Da che hai taggato WPF, per WPF, avere una proprietà di dipendenza 'StatusText', potrebbe sembrare un'altra opzione allettante, con questo approccio quando hai più proprietà di stato, hai bisogno di un modo per capire quale è ti dice lo stato più interessante che deve essere visualizzato sulla tua barra di stato ora! Che potrebbe essere un gestore di eventi modificato, multibinding (blech, complex) o dependency modificato.

Tuttavia, ti consigliamo di mantenere DependencyObjects e DependencyProperties limitati al tuo livello UI il più possibile. Il motivo è che si basano implicitamente su un Dispatcher sul thread dell'interfaccia utente e pertanto non possono essere adattati facilmente per le attività non relative all'interfaccia utente.

Poiché ci sono molte diverse parti della vostra applicazione si può anche trovare forse è ragionevole avere una combinazione di entrambi questi, utilizzando alcuni un posto e chi un'altra.

Answer 2

Preferisco le classi statiche che contengono i tuoi oggetti. Quindi la quantità di oggetti a cui puoi accedere viene ricondotta dall'interfaccia offerta dalla classe statica. Statico non è male finché l'applicazione continua a ridimensionare.

Un'altra buona alternativa ai singleton è il pattern Monostate, in cui si dispone di una classe che implementa campi statici privati ​​per rappresentare il comportamento "singleton".

Vedi:
Monostate
Monostate vs. Singleton

UPDATE: E spesso mi aiuta a mantenere un REST come api in mente, anche per le strutture interne del programma. Avere una classe che viene aggiornata da tutte le parti e inviare notifiche a tutti è difficile da controllare rispetto alle condizioni di aumento e infinito loop (Aggiorna -> Evento -> Aggiorna -> ...)

Build a (statico o no) Interfaccia della barra di stato a cui è possibile accedere dove ne hai bisogno. Attraverso una classe statica in cui si ottiene l'accesso all'interfaccia della barra di stato o all'iniezione di dipendenza se si utilizzano tali tecniche (non consigliato per progetti di dimensioni minori). Ogni chiamata all'interfaccia della barra di stato deve essere indipendente da qualsiasi evento che potrebbe essere generato dalla barra di stato per evitare ulteriori problemi con condizioni di aumento. Pensa all'interfaccia della barra di stato come un sito web che può essere chiamato da altre parti del programma per spingere e tirare le informazioni.

Answer 3

È difficile dare consigli senza conoscere più l'architettura della tua applicazione, ma forse dovresti prendere in considerazione l'iniezione di dipendenza. Ad esempio, passare un'istanza StatusBar al costruttore di ogni classe che la utilizza direttamente.

Answer 4

È possibile utilizzare semplicemente lo schema Observer e aggiungere lo StatusBar come listener ai 20 oggetti. Questo eliminerà i singleton e seguirà meglio SRP e DIP, ma dovrai valutare se vale la pena. Un singleton può essere migliore se l'indirezione aggiunge troppa complessità e l'iniezione di dipendenza non è possibile.

public class StatusBar implements StatusListener { 
} 

public interface StatusListener { 
    public statusChanged(String newStatus) 
} 

Answer 5

Le lezioni dipenderanno implicitamente su qualsiasi Singleton uso ed esplicitamente a qualsiasi parametro nel costruttore. Suggerirei di aggiungere un'interfaccia al singleton, quindi solo i metodi necessari saranno esposti alle classi usando IStatusBar. Questo è più codice, ma faciliterà il test dell'unità.