Комментарии 11
Много кода.
Мне лично хватило одного упоминания связки состояний компонентов с состояниями конечного автомата, дальше реализация практически очевидна.
P.S. Также хотелось бы заметить, что диалог удобно закрыть интерфейсом для вызывающего кода, в итоге вызывающий код вообще отвязан от диалога. Что правильно.
Мне лично хватило одного упоминания связки состояний компонентов с состояниями конечного автомата, дальше реализация практически очевидна.
P.S. Также хотелось бы заметить, что диалог удобно закрыть интерфейсом для вызывающего кода, в итоге вызывающий код вообще отвязан от диалога. Что правильно.
У вас же на каком-то этапе генерируются резанные пдфки. Почему нельзя склеивать их? Или это технически невозможно? И почему надо превращать в тяжеловесные джипеги, а не в, например, пнгшки?
Зачем изобретать велосипед, если есть MVP?
Вот вам безупречный с точки зрения архитектуры пример реализации MVP паттерна:
www.logicdevelopment.net/blog/?p=16
Вот вам безупречный с точки зрения архитектуры пример реализации MVP паттерна:
www.logicdevelopment.net/blog/?p=16
Да, такой забавный способ реализовать контроллер, который бы мог просто состоять из нескольких методов, содержащих тела методов enterState всех Стейтов. А чем он удобнее, чем простой MVC?
Просто когда слышишь слово «стейты», сразу ожидаешь увидеть возможность описывать все события в системе каким-нибудь простым стандартным образом, типа xml-файла, или, как сумашедшие немцы у нас сделали — в базе данных хранить. И типа тестировать сразу станет удобнее, потому что тестировщикам будет просто смотреть на описание требуемого поведения системы, если спеки так писать. Или вообще тесты адские делать, которые просто берут, требуемые переходы вызывают и отслеживают состояние модели.
Как говорил герой фильма «Револьвер», а что это дает мне? В чем радость?
Просто когда слышишь слово «стейты», сразу ожидаешь увидеть возможность описывать все события в системе каким-нибудь простым стандартным образом, типа xml-файла, или, как сумашедшие немцы у нас сделали — в базе данных хранить. И типа тестировать сразу станет удобнее, потому что тестировщикам будет просто смотреть на описание требуемого поведения системы, если спеки так писать. Или вообще тесты адские делать, которые просто берут, требуемые переходы вызывают и отслеживают состояние модели.
Как говорил герой фильма «Револьвер», а что это дает мне? В чем радость?
Мне кажется, что автор просто привлекает внимание к подходу/парадигме программирования, которую я называю автоматное программирование или программирование с явно выделенным состоянием. Плюсы мышления в подобном стиле велики, но не все знают о таких способах борьбы со сложностью, потому такие статьи надо приветствовать.
Этот подход может реализоваться разными способами: от банального switch до полноценного фреймворка — что лучше зависит от контекста.
Этот подход может реализоваться разными способами: от банального switch до полноценного фреймворка — что лучше зависит от контекста.
Всё верно. Поэтому в конце статьи и привел ссылку на SwingStates для всех желающих, которые хотели бы более глубоко изучить такой подход к написанию пользовательских интерфейсов.
Например, можно параллельно поддерживать в одном диалоге несколько разных View. Достаточно одновременно иметь несколько конечных автоматов, каждый из которых будет помнить своё состояние. Здесь есть замечательный пример как это выглядет.
Я пока еще сам полностью не разобрался с SwingStates фреймворком, но в некоторых ситуациях он действительно может помочь при написании сложных диалогов.
Опять же в SwingStates есть специальные дебаг-конечные-автоматы, с помощью которых можно очень наглядно увидеть, что у вас происходит в диалоге.
P.S. Добавил в код примера реализацию с помощью MVC.
Я пока еще сам полностью не разобрался с SwingStates фреймворком, но в некоторых ситуациях он действительно может помочь при написании сложных диалогов.
Опять же в SwingStates есть специальные дебаг-конечные-автоматы, с помощью которых можно очень наглядно увидеть, что у вас происходит в диалоге.
P.S. Добавил в код примера реализацию с помощью MVC.
Поздравляю! Вы придумали шаблон состояние. Честно говоря, назвать это конечным автоматом я бы не решился. Хотя в некотором смысле можно так полагать.
Использовал подбный подход в дипломе — сложной распрееленной системе, с помощью автомата/состояние описывалось поведение каждой ноды в замисимости от внешних факторов.
Использовал подбный подход в дипломе — сложной распрееленной системе, с помощью автомата/состояние описывалось поведение каждой ноды в замисимости от внешних факторов.
А если смотреть в сторону предметно-ориентированных языков (DSL), вот еще две недавние публикации на Хабре:
habrahabr.ru/blogs/Flash_Platform/128725/
habrahabr.ru/blogs/Flash_Platform/129092/
И не надо смущаться, что оба упомянутых поста находятся в блоге Flash_Platform, поскольку речь идет о Jetbrains MPS-based IDE.
habrahabr.ru/blogs/Flash_Platform/128725/
habrahabr.ru/blogs/Flash_Platform/129092/
И не надо смущаться, что оба упомянутых поста находятся в блоге Flash_Platform, поскольку речь идет о Jetbrains MPS-based IDE.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий
Реализация графического интерфейса как Конечного Автомата