Шаблоны проектирования, которые разделяют модели данных и графическое представление

Question

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

Так, скажем, у меня есть класс Circle и класс Square, тогда я бы испытал желание использовать метод draw в обоих этих классах. Однако это заставит класс импортировать все виды неприятных вещей в зависимости от используемого ими холста для рисования (swing, j3d, opengl и т. Д.).

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

Есть предложения по этому поводу?

Answer 1

Шаблон Model View Controller , вероятно, наиболее часто используется. Swing в значительной степени опирается на этот паттерн, где Decorator (который используется для таких вещей, как полосы прокрутки) и Strategy (менеджеры раскладки и т. Д.) Кажутся поддерживающими паттернами.

Что касается альтернатив MVC, вы можете взглянуть на Model View Presenter , но в большинстве реализаций полное разделение будет сильно зависеть от некоторой шины событий, в случае Swing в Наблюдатель (слушатели событий).

Решение datamodel / gui, по-видимому, представляет собой небольшую проблему, но на самом деле довольно сложно правильно управлять указанной шиной событий.

Мой любимый способ сделать это - использовать шаблон Command . Использование шины событий для передачи различных команд делает разделение несколько чистым. Модель данных выполняет команду некоторым способом (обычно используя связанный объект-обработчик команды), и затем вызывается обратный вызов.

Это на самом деле прославленный MVC, поскольку класс, выполняющий команду, в конечном итоге становится вашим контроллером, но шаблон позволяет модели / контроллеру знать только об объектах обратного вызова. В зависимости от характера вашей программы вы можете реализовать набор классов, о которых знает только представление, используя шаблон Data Transfer Object . Это мой предпочтительный подход к асинхронным приложениям, таким как GWT.

В настольных приложениях и приложениях для Android вы по-прежнему выполняете асинхронно (Context.runOnUiThread() и SwingUtilities.invokeLater() диктуют это), и, следовательно, шаблон команды подходит. Независимо от того, являются ли DTO лучшим подходом для вашего приложения, зависит, но они больше всего конечно отделите модель от вида.

Answer 2

Нет «лучшего» метода, все зависит от вашей платформы, архитектуры и прочего. Обычно, когда дело доходит до GUI, несколько шаблонов должны быть объединены. Одним из них обычно является MVC , где представление может быть расширено другим шаблоном иерархии (посетитель также является опцией).

Answer 3

Я думаю, что вы можете добиться успеха, используя стратегию шаблон или композицию .

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

Answer 4

Шаблон Designrator Design также может быть применен к инструментарию GUI для динамического добавления поведения.

Answer 5

Специализированный случай MVC, который может представлять интерес: Model View Presenter .

Answer 6

Да, вы ищете шаблон MVC. Swing, например, использует MVC. Вы определяете модель для табличных данных в интерфейсе TableModel. Тогда это до Компонента, как сделать это. JTable отображает его в табличной форме. Пользовательский JPieChart может отображать его в виде круговой диаграммы. C в MVC обозначает контроллер и позволяет обновлять модель при взаимодействии пользователя с графическим интерфейсом.