GUI как конечный автомат - PullRequest
       19

GUI как конечный автомат

12 голосов
/ 26 октября 2009

Для реализации графического интерфейса приложения я бы хотел, чтобы вся логика переходила из одной формы в другую централизованно. Этот менеджер GUI будет вести себя как конечный автомат. Хотя я думаю, что где-то видел подобную реализацию, я не могу найти шаблон проектирования, который бы соответствовал этому виду решения.

Форма будет выглядеть так:

public class Login : Form
{
    ...

    private void EnterButton_Click()
    {
        ...

        string user = loginTextBox.Text;
        string password = passwordTextBox.Text;
        bool isValid = SecurityManager.CheckUserLogin(user,password);

        GUIManager.FormEnd(FormLogin,new LoginData(user, pass, isValid));
    }

    ...
}

И менеджер GUI сделает что-то вроде этого:

public class GUIManager
{
    ...

    public void FormEnd(FormType type, FormData data)
    {
        switch (type)
        {
            ...
            case FormLogin:
                LoginData ld = (LoginData)data;
                if (ld.Valid)
                {
                    m_loginForm.Hide();
                    m_mainForm.Show();
                }
            ...
        }
    }

    ...
}

Достигнув этой точки, у меня возникли следующие вопросы: существует ли модель проектирования, которая формализует эту идею? Если есть, то .NET поддерживает это как-то? Если нет, это звучит как хорошая идея реализации? Спасибо!

Ответы [ 3 ]

6 голосов
/ 26 октября 2009

Шаблон проектирования состояния описывает, как реализовать конечный автомат.

Существует множество слегка отличающихся шаблонов проектирования для управления экранами в пользовательском интерфейсе, но я думаю, что шаблон проектирования Application Controller соответствует тому, что вы пытаетесь сделать.

4 голосов
/ 26 октября 2009

Это отличная идея! Фактически, он настолько хорош, что это было сделано раньше и, вероятно, является наиболее распространенным шаблоном, используемым при разработке расширяемых приложений (подумайте о таких средах разработки, как Visual Studio, Eclipse и т. П.).

Один пример, SCSF (который использует CAB) , из MS Patterns and Practices Group, использует этот шаблон "из коробки" для создания подключаемых и расширяемых составных приложений в WinForms и WPF. Фактический шаблон, который он использует, включает в себя создание иерархических конечных автоматов, называемых WorkItems, которые управляют сценариями использования и проходят через приложение. Я бы посмотрел, как парни из Patterns и Practices сделали это, прежде чем я реализовал это как свое собственное детище. Я использовал это много раз, и оно того стоит.

1 голос
/ 26 октября 2009

В мире Java вы можете думать о приложении Struts или JSF как о FSM (это событие на этой странице / состоянии приводит нас к этой странице / состоянию.

При моделировании потоков в традиционном веб-интерфейсе я обнаружил, что использование FSM является чрезвычайно полезным инструментом анализа. Вы можете очень быстро уловить суть поведения приложения. Было в значительной степени однозначное соответствие между page и state . Я хотел бы иметь модель состояния и связанные модели данных.

Теперь у нас есть более богатые пользовательские интерфейсы, использующие AJAX, соответствие между состояниями приложения и «страницами» менее очевидно. Однако вы все еще можете рассуждать о поведении приложения: здесь пользователь делает this , когда он закончил, он может выполнить действия X или Y и затем он может that . Таким образом, состояния, события и переходы все еще существуют, просто их представление немного более «виртуально».

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...