Как правильно отделить логику структуры данных от ее графического представления?

Question

Это больше вопрос проектирования программного обеспечения, чем строго программирования, поэтому я буду вставлять UML-диаграммы вместо кода для удобства всех.

Язык - это Java, поэтому переменные являются подразумеваемыми ссылками.

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

При первом пробном запуске я ''Мы включили весь связанный с рисованием и оптимизационный код в структуру данных, то есть каждый узел знал, как рисовать себя, и держал ссылку на одно из общих кэшированных растровых изображений.UML:

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

Так что на следующей итерации я решил разделить вещи, но, возможно, я пошел далеко, и все снова стало грязно:

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

Классическим способом было бы изменить данные, а затем вызвать invalidate() в оболочке чертежа, но это неэффективно для многих небольших изменений.Например, чтобы удалить 1 Tile Id, необходимо, чтобы представление Drawn было независимым от Data, и вызывать deketeTile() для обоих по отдельности, или направлять все команды в Data через класс Drawing.Все становится еще сложнее, когда я пытаюсь добавить различные методы рисования через шаблон Стратегии или как-то еще.Ужас:

Что такое чистый эффективный способ организации взаимодействий с Model и View?

Answer 1

Во-первых, определенно отделите логику приложения от пользовательского интерфейса.Сделайте модель для вашей схемы.Это решит вашу проблему с модульным тестированием модели приложения, как вы уже сказали.Тогда я бы попробовал шаблон Observer .Но, учитывая, что схема может содержать множество графических компонентов (ваши плитки), я бы изменил обычную настройку уведомления каждого наблюдателя об изменении модели в уведомлении только о соответствующем GraphicalComponent (плитке) при изменении компонентав модели.Ваш пользовательский интерфейс просит модель сделать что-то, и в некоторых частях его перезванивают для обновления.Это будет автоматически, без дублирующих вызовов, просто начальный реестр наблюдателей при создании GraphicalComponent.