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

Question

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

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

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

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

****** Head Desk *****

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

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

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

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

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

Answer 1

Вы слышали о Мартине Фаулере?

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

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

Answer 2

Как правило, в точке разделения:

1. Мало того, что разные компоненты пользовательского интерфейса могут отображать одну и ту же структуру данных.У вас могут даже быть совершенно разные пользовательские интерфейсы (веб, настольное приложение, ...) Теперь, конечно, вы можете создать подкласс Person с WebPerson и DesktopPerson (это уже звучит неправильно, не так ли?именование просто не о человеке - это о чем-то другом) .

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

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

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

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

Answer 3

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

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