Я немного запутался в определении классов как моделей или представлений в примере приложения AppKit Sketch (находится в /Developer/Examples/AppKit/Sketch). Классы SKTRectangle, SKTCircle и т. д. считаются классами моделей, но имеют код рисования.
У меня сложилось впечатление, что модели должны быть свободны от кода вида/чертежа.
Может ли кто-нибудь прояснить это?
Спасибо.
Разработчик Sketch немного излагает свое обоснование в файле ReadMe:
Дизайн модели-представления-контроллера
Слой модели Sketch в основном состоит из класса SKTGraphic и его подклассов. Документ эскиза состоит из списка SKTGraphics. SKTGraphics — это в основном классы, несущие данные. Каждое изображение содержит всю информацию, необходимую для представления любого вида изображения. Класс SKTGraphic определяет набор примитивных методов для изменения графики, а некоторые подклассы добавляют собственные новые примитивы. Класс SKTGraphic также определяет некоторые расширенные методы для изменения графики, которые реализованы в терминах примитивов.
Класс SKTGraphic определяет набор методов, позволяющих рисовать самого себя. Хотя может показаться, что это не совсем то, что должно быть частью модели, имейте в виду, что то, что мы моделируем, представляет собой набор визуальных объектов. Несмотря на то, что SKTGraphic знает, как отображать себя в представлении, это не само представление.
Не знаю, удовлетворит вас этот ответ или нет. Мой личный опыт работы с MVC заключается в том, что, хотя разделение модели, представления и контроллера является «хорошей вещью», на практике границы между слоями часто становятся размытыми. Я думаю, что компромиссы дизайна часто делаются для удобства.
В частности, для Sketch мне кажется логичным, что модель умеет рисовать себя внутри вида. Альтернативой тому, чтобы каждый подкласс SKTGraphic знал, как рисовать себя, было бы наличие класса представления со знанием каждого подкласса SKTGraphic и того, как его визуализировать. В этом случае добавление нового подкласса SKTGraphic потребует редактирования класса представления (вероятно, добавления нового предложения в оператор if/else или switch). С текущим дизайном можно добавить подкласс SKTGraphic без каких-либо изменений в классах представлений, чтобы все заработало.
Я не знаю конкретного примера, на который вы ссылаетесь, но вот мое предположение о причине этого дизайна:
Возможно, Модели (упомянутые вами SKTRectangle, SKTCircle) знают достаточно, чтобы рисовать самих себя, но недостаточно, чтобы фактически выполнять рисование на экране. Отрисовка на экране обрабатывается представлением, где представление вызывает модели, чтобы выяснить, как их отрисовывать на экране.
При таком подходе представлению не нужно знать, как отрисовывать каждую модель, с которой оно может столкнуться — представлению нужно только знать, как попросить модель отрисовать себя на экране.
Я думаю, что это компромисс между моделью MVC и моделью объектно-ориентированного программирования - строгое разделение по линии MVC будет означать, что представление станет чрезвычайно большим и не очень гибким, когда дело доходит до добавления поддержки для другие модели, которые необходимо отобразить. При объектно-ориентированном дизайне мы хотели бы, чтобы сами Модели могли рисовать себя на экране, и мы хотели бы, чтобы Представление могло обрабатывать новые типы Моделей с помощью таких средств, как интерфейсы.
