Как классы в примере приложения Sketch AppKit разделены на Models / Views / Controllers?

Question

Меня немного смущает определение классов как Моделей или Представлений в примере приложения App Sit Sketch (находится в / Developer / examples / AppKit / Sketch). Классы SKTRectangle, SKTCircle и т. Д. Считаются классами модели, но имеют код для рисования.

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

Может кто-нибудь прояснить это?

Спасибо.

Answer 1

Разработчик Sketch изложил свое обоснование в файле ReadMe:

---

Модель-представление-дизайн контроллера

Слой модели Sketch - это в основном класс SKTGraphic и его подклассы. Документ Sketch состоит из списка SKTGraphics. SKTGraphics - это в основном классы с данными. Каждый графический объект содержит всю информацию, необходимую для представления любого графического изображения. Класс SKTGraphic определяет набор примитивных методов для изменения графики, а некоторые из подклассов добавляют свои собственные новые примитивы. Класс SKTGraphic также определяет некоторые расширенные методы для изменения графики, которые реализованы в терминах примитивов.

Класс SKTGraphic определяет набор методов, которые позволяют ему рисовать себя. Хотя может показаться, что это не является частью модели, имейте в виду, что то, что мы моделируем, представляет собой набор визуальных объектов. Хотя SKTGraphic знает, как визуализировать себя в представлении, это не само представление.

---

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

Для Sketch, в частности, для меня имеет смысл, что модель знает, как рисовать себя внутри вида. Альтернативой тому, чтобы каждый подкласс SKTGraphic знал, как рисовать себя, было бы иметь класс представления со знанием каждого подкласса SKTGraphic и способ его визуализации. В этом случае добавление нового подкласса SKTGraphic потребует редактирования класса представления (вероятно, добавление нового предложения в оператор if / else или switch). С текущим дизайном можно добавить подкласс SKTGraphic без каких-либо изменений, необходимых для классов представлений, чтобы все заработало.

Answer 2

Мне неизвестен конкретный пример, на который вы ссылаетесь, но вот мое предположение о причине такого дизайна:

Возможно, модели (SKTRectangle, SKTCircle, о которых вы упомянули) знают достаточно, чтобы нарисовать , но недостаточно, чтобы фактически выполнить рисование на экране. Рисование на экран обрабатывается представлением, где представление вызовет модели, чтобы узнать, как нарисовать их на экране .

Используя этот подход, Представление не должно знать, как рисовать каждую отдельную Модель, с которой оно может столкнуться - Представлению нужно только знать, как попросить Модель нарисовать себя на экране .

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