Как объяснить кому-то, что структура данных не должна тянуть себя, объясняя разделение проблем?

У меня есть другой программист, которого я пытаюсь объяснить отчего получается, что компонент UI не должен также быть структурой данных.

Например, скажите, что Вы получаете структуру данных, которая содержит официальный набор документов от "базы данных", и Вы хотите отобразить тот официальный набор документов в компоненте UI в рамках Вашего приложения.

По словам этого программиста (кто останется неназванным, он молод и я учу его...), мы должны разделить структуру данных на подклассы в класс, который потянет компонент UI в рамках нашего приложения!!!!!!

И таким образом согласно этой логике, официальный набор документов должен управлять рисунком UI.

****** Главный Стол *****

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

Я хорошо знаю о "чистоте" шаблона MVC (и тем, что то, что я действительно имею в виду, является Вами, не путают Ваши данные (Модель) с Вашим UI (представление) или действия, которые происходят на данных (Контроллер более или менее... хорошо не действительно, API должен действительно обработать это..., и Контроллер должен просто выполнить так мало вызовов к нему, как это может, говоря это, какое представление представить)), Но это, конечно, намного более чисто, чем использование структур данных для рендеринга компонентов UI!

Есть ли совет, который я мог отправить его пути кроме примера выше? Я понимаю, что, когда Вы сначала изучаете ООП, Вы проходите "этап", где Вы, где просто хотят расширить все.

Сопровождаемый этапом, когда Вы думаете, что Шаблоны разработки являются решением каждая проблема..., которая не совершенно корректна, любой... благодарит Jeff.

Существует ли способ, которым я могу мягко пошагово переместить этого ребенка в правильном направлении? У Вас больше есть примеры, которые могли бы помочь объяснить мою идею ему?

5
задан leeand00 18 March 2010 в 22:10
поделиться

3 ответа

Слышали ли вы о Мартине Фаулере?

Разделение пользовательского интерфейса Код

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

4
ответ дан 15 December 2019 в 00:57
поделиться

Это сводится к функциональным и нефункциональным обязанностям. Что делает структура данных и как она визуализируется - это две совершенно разные вещи - по сути, корень шаблона MVC.

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

0
ответ дан 15 December 2019 в 00:57
поделиться

Вообще по поводу развязки:

  1. Мало того, что разные компоненты пользовательского интерфейса могут рендерить одну и ту же структуру данных. Вы даже можете иметь совершенно разные пользовательские интерфейсы (Web, Desktop Application, ...) Конечно, вы можете подклассифицировать Person с WebPerson и DesktopPerson (это уже звучит неправильно, не так ли? Просто именование не связано с типом Person - оно связано с чем-то другим).

  2. Каждый пользовательский интерфейс может работать с разными типами персон, например, Teacher и Student. Таким образом, мы получаем WebPerson, WebTeacher, WebStudent, DesktopPerson, DesktopTeacher и DesktopStudent.

Теперь допустим, WebPerson определяет метод "drawAddressFields()" для рисования веб-версии полей адреса. Но поскольку WebTeacher должен быть производным от Teacher, чтобы использовать дополнительное поле данных "зарплата" (и давайте предположим одинарное наследование), он должен реализовать "drawAddressFields()" еще раз!

Так что, возможно, аргумент "это вызовет гораздо больше работы" поможет создать некоторую мотивацию :-)

BTW, это автоматически приведет к созданию некоторого делегата, реализующего код drawAddressField(), который затем перерастет в создание компонента, выполняющего рисование отдельно от структуры данных.

0
ответ дан 15 December 2019 в 00:57
поделиться
Другие вопросы по тегам:

Похожие вопросы: