Separazione delle preoccupazioni per una classe "Manager"

Question

Separazione delle preoccupazioni per una classe "Manager"

#1 da (3 voti)
#2 da (2 voti)
#3 da (0 voti)

5

Ho una classe che "controlla" lo stato attuale dell'applicazione, ApplicationStateManager . Ho un Enum che elenca gli stati possibili per l'applicazione

enum ApplicationState
{ 
    Idle,
    Starting,
    Started,
    Stopping,
    Stopped
}

ApplicationStateManager contiene membri come:

public static ApplicationState CurrentState = ApplicationState.Idle;

public static void ChangeCurrentState(ApplicationState newState)
{
      CurrentState = newState;
}

Potrei interrogare il campo statico CurrentState usando ApplicationStateManager.CurrentState; per vedere se posso continuare l'esecuzione del codice o qualcosa del genere.

Ora la domanda è che stavo cercando di separare le preoccupazioni avendo un ApplicationStateChanger ma il problema è, dove incollare la variabile CurrentState ?

c# design-patterns solid separation-of-concerns

posta Joao Vitor 03.11.2017 - 01:56

fonte

3 risposte

Leggi altre domande sui tag c# design-patterns solid separation-of-concerns

L'involucro di una risorsa hardware utilizza il polimorfismo andando troppo oltre? Per GPL, i modelli di rete neurale addestrati contano come codice sorgente?

score 3 · Answer 1

Se il comportamento della tua applicazione dipende dallo stato in cui si trova, allora questo è un chiaro indicatore che potresti voler implementarlo come Macchina a stati finiti .

Questo può essere ottenuto utilizzando Pattern di stato o Visitor Pattern . Dovresti usare la versione precedente se il numero di stati è soggetto a modifiche più frequenti, e quest'ultimo se il numero di eventi che possono innescare cambiamenti di stato è soggetto a modifiche più frequenti.

score 2 · Answer 2

I have a Class that "controls" the current application state, ApplicationStateManager

L'applicazione dovrebbe essere l'unica responsabile del suo stato. È il tratto fondamentale di OOP chiamato incapsulamento . Qualsiasi oggetto in OOP è responsabile del mantenimento del proprio stato.

Now question is I was trying to separate concerns by having a ApplicationStateChanger

Per le ragioni sopra esposte, non dovrebbe esserci una tale classe. L'applicazione dovrebbe essere responsabile della modifica del suo stato.

but the problem is, where to stick the CurrentState variable?

Potresti provare a implementare uno schema di stato come suggerito da Vladimir Stokic. Ma questo potrebbe essere eccessivo dato che sembra che la tua logica di cambiamento dello stato sia strettamente sequenziale. Quindi un altro approccio consiste nell'implementare un insieme di oggetti immutabili:

class Idle implements Application
{
    public function __construct()
    {
    }

    public function next()
    {
        return new Starting();
    }
}

class Starting implements Application
{
    public function __construct()
    {
    }

    public function next()
    {
        return new Started();
    }
}

Se disponi di funzionalità mutua per tutti gli stati, o Context, in termini di pattern State, allora lo stesso codice potrebbe essere implementato con ereditarietà o con Decorator pattern , ma non sono a conoscenza delle tue specifiche per approfondire molti dettagli.

score 0 · Answer 3

Now question is I was trying to separate concerns by having a ApplicationStateChanger but the problem is, where to stick the CurrentState variable?

L'esempio di codice fornito mostra solo alcuni getter e setter per lo stato dell'app. Abbiamo bisogno di maggiori dettagli per discutere qualsiasi cosa sulle preoccupazioni.

Per ora, con questi pochissimi dettagli, avrei qualche classe Application, con il suo getter / setter per il suo stato, e qualche altro oggetto esterno designato per cambiare questi stati in base a circostanze specifiche.