Оберон / Компонентный Паскаль / Вики

Эта страница только для чтения. Вы можете посмотреть её исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.
===== 3.4  Составные документы =====

==== 1. Что такое документ ====
Как только среднестатистический человек слышит слово "документ" -- ему представляется лист бумаги формата А4 с заголовком, подписями, реквизитами, и желательно -- большой круглой синей печатью. Ну правда, а какие ещё документы бывают? Немного подумав, можно обратиться в архив, и из хранилища можно извлечь что-то вроде "Повести временных лет". В кожаном переплёте, с металлическим окладом, с красивыми рисунками. Документ? Для историков ещё какой! Спросим следователя, что для него документ? Он тут же достанет специальный пакет, в котором хранится гипсовый слепок обуви преступника. Вот для него настоящий документ! Таким образом, понятие документ вовсе не ограничивается листом бумаги формата А4.


==== 2. Документ BlackBox ====
Документ BlackBox может иметь вид какой угодно. Этот текст -- самый настоящий документ БлэкБокс. Код программы на Компонентном Паскале в БлэкБокс -- такой же документ. Даже текст программы внутри текста этого учебника -- тоже документ (обратите внимание: документ внутри документа!). Причём, на страницах этого учебника встречались такие документы, которые содержат и текст, и код, и изображения. При этом БлэкБокс не сходит с ума, и прекрасно понимает, что к чему относится, и что с этим делать. Последние два подчёркивания особо отмечают то, что документ БлэкБокса имеет более сложную структуру, чем печатный текст.
	
	
==== 3. Как это работает? ====
Для начала обратимся к аналогии в виде дорожно-транспортной системы. Она нужна для того, чтобы автомобили могли успешно перемещаться. Автомобили бывают разные: большие, маленькие, тяжёлые, красные -- миллионы их. И если большие автомобили ещё могут проехать по бездорожью, то маленькие нет. А ездить только на больших атомобилях экономически нецелесообразно. Нужно делать транспортную сеть. Такая сеть представлена: улицами, проспектами, шоссе, площадками. Теперь, когда все автомобили обрели твёрдую поверхность под колёсами, можно ездить как попало. Ан нет! Автомобили будут постоянно сталкиваться, и толку от них не будет. Нужна дорожная разметка! Нанесли разделительные полосы, поставили знаки/светофоры, кое-где информационные (но не обязательные) указатели, и вроде можно жить. И этого оказывается мало! Нужно разработать непротиворечивые объемлющие правила дорожного движения, и добиться их исполнения ото всех участников дорожного движения. И вот только тогда, действительно, можно жить. Автомобиль -- это текст. Или файл. Или объект. Носитель информации. И сам по себе он уже полезен, но роль у него исключительно пассивная, и в этом смысле -- что-либо с ним сделать нельзя, и в гараже его не видно. Гараж, как и улица, как и проспект -- это то, что может представить объект. То, что может представить объект, может это сделать по разному. Например, модель "гоночный автомобиль" лучше будет смотреться на скоростном треке, а на пашне будет бесполезен. Модель "танк" будет нелепо смотреться на центральных улицах города, а на поле боя -- превосходно! Таким образом, мы плавно приходим к мысли, что представление объекта задаётся его моделью. Но автомобиль, который едет по дороге, фактически, изменяет своё состояние. Например, гоночный автомобиль быстро разгоняется, и тем самым меняет свою скорость и кинетическую энергию. А танк может быть перекрашен, в зависимости от времени года. И изменения эти происходят не как попало, а задаются в соответствии с логикой внеших условий. Этот набор задающих внешних условий в программостроении принято называть контроллер. Например, знак на дороге вынуждает повернуть автомобиль. Конечно, автомобиль, может развернуться и уехать -- его право, но если захочет поехать дальше, то обязан подчиниться требованиям дорожной  разметки.

Итак, дорожно-транспортная сеть помогает успешно перемещаться автомобилям, но в тоже время, и ограничивает (для их же пользы) возможные варианты действий. Это каркас. И чтобы он (каркас) успешно функционировал нужно иметь три типовых элемента по отношению к заполняющим его (каркас) объектам: представление, модель, контроллер.
	
	
==== 4. Представление, модель, контроллер ====
Ещё раз стоит повторить: сейчас речь идёт не о объектах, внутри каркаса, а о самом каркасе. Текст вовсе не обязан находиться внутри документа, и именно так часто и происходит: можно до сих пор наблюдать файлы, типа READ.MY, Log.txt и т. д. Для таких кусков текста каркасом будет операционная система, а моделью будет файловая система; представлением будет простейший текстовый редактор, и функции контроллера будут распределены в неравных долях между простейшим текстовым редактором и символами форматирования внутри самого текстового файла. Как можно понять -- это не очень-то хорошо, что функции контроллера разделены между элементами каркаса. Это наводит на мысли о том, что идея хранить текст внутри текстового файла -- не самая хорошая идея. На самом деле, а что будет, если кодировка поменяется? Или как убедиться, что текстовый файл не повреждён? А если возникнет желание задать отступы, интервалы, размер шрифта?

Поэтому люди, например, в лице Тима Бернерса-Ли, для решения насущной задачи "как правильно отобразить текст по заданной модели" придумал разметку HTML. Необходимость была вызвана тем, что браузер понятия не имел, как автор задумывал, чтобы вглядела страница. А таких авторов, в этих ваших интернетах -- легион. В какой-то момент, кто-то подумал: форматирование HTML-страниц повторяется из раза в раз. Может вынести все эти правила, стили, начертания в отдельный файл, а во всех создаваемых HTML-страницах только оставить типы оформлений, которые описаны в этом общем файле? И был придумал CSS. Но, большое количество оформления всё ещё можно найти в HTML-страницах. Т.е. современный Web так до сих пор и не избавился от детской болезни под названием смешение объекта и модели.

Объект, в виде HTML-страницы часто содержит программный код для оживления самой страницы. Частично, его тоже сейчас выносят в отдельные файлы, оставляя внутри лишь одни ссылки. Но не всегда. Фактически, речь идёт о том, что в объект пытаются насильно запихнуть элементы контроллера, который на самом деле является внешним объектом по отношению к самому объекту. В идеале, объект не должен содержать в себе никаких частей контроллера (кроме той части, что является интерфейсом). И объекту должно быть всё-равно, что с ним делает контроллер.

А контроллер подгоняет объект, по заданой модели к необходимому представлению. Контроллеров, по отношению к объекту представления, может быть даже несколько (если такая необходимость реально возникает). Например, контроллер может по заданной модели сделать текст в масштабе пропорционально меньше, или произвести подмену шрифтов, или перекодирование символов из кодировки cp1251 в более прогрессивную UTF-8. Такие действия могут быть вызваны спецификой представления объекта.

Представление, обычно последний уровень в этой концепции. Обычно, представление, зависит от аппаратных средств. Например, это может быть цветной монитор, или чёрно-белый принтер, или цветной (и довольно грубый) плоттер. В каждом случае представление своё. Должен ли знать файл с текстом, в какой кодировке работает операционная система, как его выравнивают, подгоняют, с какой точностью отображают, и должен ли знать текстовый файл о том, какие существуют в мире модели принтеров, или будут существовать, чтобы правильно отобразить себя на всех доступных поверхностях?

Таким образом, если схематчно представить эту концепцию подчинённости, то она будет выглядеть примерно  так [1]:

{{ :bb:redbook:mvc.png?nolink&600 |}}

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

Собственно, вот так и работает документ БлэкБокс. Документ содержит объект (например текст, код, картинку) с необходимыми атрибутами для успешного использования объекта (по сути, элементы модели), модели задают правила представления объекта (например, красный цвет заголовка, или жирный текст кнопки), контроллер документа подгоняет его под требования представления (окна, кнопки, меню и т. д.). Изменятся глобальные настройки системы -- контроллер опять подгонит объект по правилам модели к новому представлению.
FIXME --- //[[prospero.78.su@gmail.com|Валерий Шипков]] 2016/03/31 15:53//(* здесь бы добавить мысль про то, что контроллер является главным в системе *)



==== 5. Выводы ====
Каркас обеспечивает существенные возможности для документов. Каркас вносит свою сложность в создаваемую систему. Но эта сложность многократно компенсируется тем, что каркас берёт ещё большую сложность на себя. В частности, документы БлэкБокса помогают программисту единообразно работать с текстами, переносить код между системами, организует работу наиболее рациональным способом. Локально снижаемая сложность приводит к более эффективной работе с объемлющими сложностями. [↑]


[1] Фримен Э. и др. Паттерны проектирования. Санкт-Петербург: Питер, 2011. 656 c.

[ ← Назад ]				[ Вверх ↑ ]				[ Далее → ]