Um aplicativo GUI simples: states

5

Estou criando um aplicativo do Windows Forms:

  • É cliente-servidor. Autorização, carregue alguns dados do servidor e envie algumas estatísticas de tempos em tempos.
  • Você deve passar por um procedimento de bootstrapping e, em seguida, inicia os cálculos (um processo separado). Depois, você pode pausar a qualquer momento, provavelmente agendá-lo para iniciar a computação novamente ou encerrá-lo completamente.

Meu código está cheio de verificações como "Esses dados estão disponíveis? Carregue-os no servidor". ou "Estes dados estão disponíveis? Prompt do usuário". ou "É um começo está agendado? Cancele, comece agora.".

Eu sinto que meu aplicativo é uma máquina de estado. É como se tivesse um estado assim: AUTH / WORKING / PAUSED / PAUSED_SCHEDULED / SHOWING_ERROR_MSG mais um monte de sinalizadores de disponibilidade de dados. Meu código inicia transições de estado para estado e as executa, basicamente, tenta manter o aplicativo em um estado correto. O código está confuso com verificações de disponibilidade de dados, bootstrapping longo em cada método, toneladas de código de repetição de falhas em todos os lugares.

Existem padrões e estruturas de design que eu possa usar? Existe algo bom e amplamente usado? Há alguma ressalva que eu negligencie? Parece que meu código pode ser um nível mais alto.

    
por Andrey Moiseev 19.12.2016 / 21:58
fonte

2 respostas

1

Sem contexto específico, é difícil dar um conselho sobre a melhor abordagem.
Com base nas informações fornecidas, você tem poucos estados principais de sua inscrição

  • AUTH
  • TRABALHANDO
  • EM PAUSA
  • PAUSED_SCHEDULED
  • HOWING_ERROR_MSG

Você pode introduzir a abstração de todos os estados, portanto, toda implementação dessa abstração terá responsabilidade somente pela lógica do estado correspondente.

O principal objetivo dessa abordagem move a "validação" para a camada mais alta possível do seu aplicativo.

public interface IState
{
    void DoJob();
}

public class Authorization : IState
{
    public void DoJob()
    {
        // Don't need any validation -> 
        // only use validated result for this particular case
        // do authorization logic
    }
}

// And so on for other states

Se, por exemplo, WORKING state tiver lógica diferente com base nos resultados de validação de dados, você poderá introduzir a própria implementação de IState para cada ramificação possível do resultado de validação

public class WorkingWithData : IState
{
    public void DoJob()
    {
        // do working with data logic
    }
}

public class WorkingWithNoData : IState
{
    public void DoJob()
    {
        // do working with no data logic
    }
}
    
por 01.01.2017 / 13:07
fonte
2

Definitivamente, um candidato ao padrão Model-View-Controller .

Parte da complexidade em seus aplicativos, representada por meio de sinalizadores, desaparecerá se você puder identificar diferentes MODELOS / VIEWS de seu aplicativo.

Do wiki: link

The model directly manages the data, logic, and rules of the application. A view can be any output representation of information, such as a chart or a diagram. Multiple views of the same information are possible, such as a bar chart for management and a tabular view for accountants. The third part, the controller, accepts input and converts it to commands for the model.[7]

Como apontado no comentário, uma especialização do MVC, o padrão ModelViewPresenter será ainda mais adequado para este cenário. link

Model–view–presenter (MVP) is a derivation of the model–view–controller (MVC) architectural pattern, and is used mostly for building user interfaces. MVP is a user interface architectural pattern engineered to facilitate automated unit testing and improve the separation of concerns in presentation logic:

The model is an interface defining the data to be displayed or otherwise acted upon in the user interface. The presenter acts upon the model and the view. It retrieves data from repositories (the model), and formats it for display in the view. The view is a passive interface that displays data (the model) and routes user commands (events) to the presenter to act upon that data.

    
por 20.12.2016 / 10:18
fonte