Separação de preocupações para uma classe "Manager"

5

Eu tenho uma classe que "controla" o estado atual do aplicativo, ApplicationStateManager . Eu tenho um Enum que lista os estados possíveis para o aplicativo

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

ApplicationStateManager contém membros como:

public static ApplicationState CurrentState = ApplicationState.Idle;

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

Eu poderia consultar o campo CurrentState estático usando ApplicationStateManager.CurrentState; para ver se posso continuar a execução do código ou algo assim.

Agora, a questão é que eu estava tentando separar as preocupações por ter um ApplicationStateChanger , mas o problema é: onde colocar a variável CurrentState ?

    
por Joao Vitor 03.11.2017 / 01:56
fonte

3 respostas

3

Se o comportamento do seu aplicativo depender do estado em que se encontra, esse é um indicador claro de que você pode querer implementá-lo como um Máquina de Estado Finito .

Isto pode ser conseguido usando o Padrão de Estado ou Padrão de visitantes . Você deve usar o ex se o número de estados estiver propenso a mudar com mais frequência e o segundo se o número de eventos que podem acionar a mudança de estado estiver sujeito a mudanças mais frequentes.

    
por 03.11.2017 / 13:43
fonte
2

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

O aplicativo deve ser o único responsável por seu estado. É o traço fundamental do OOP chamado encapsulamento . Qualquer objeto na OOP é responsável por manter seu próprio estado.

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

Por razões declaradas acima, não deve haver tal classe. A aplicação deve ser responsável por alterar seu estado.

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

Você poderia tentar implementar um padrão de estado como foi sugerido por Vladimir Stokic. Mas isso pode ser um exagero, já que parece que sua lógica de mudança de estado é estritamente seqüencial. Então, outra abordagem é implementar um conjunto de objetos imutáveis:

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 você tiver alguma funcionalidade mútua para todos os estados, ou Contexto, em termos de Padrão de estado, o mesmo código poderá ser implementado com herança ou com Padrão do decorador , mas não estou ciente dos seus detalhes para se aprofundar em muitos detalhes.

    
por 05.11.2017 / 16:13
fonte
0

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

O exemplo de código fornecido mostra apenas alguns getter e setter para o estado do aplicativo. Precisamos de mais detalhes para discutir qualquer coisa sobre preocupações.

Por enquanto, com esses poucos detalhes, eu teria alguma classe Application, com seu getter / setter para seu estado, e algum outro objeto externo designado para alterar esses estados com base em circunstâncias específicas.

    
por 03.11.2017 / 16:45
fonte