Мы рассмотрели общее устройство программы в виде дерева рабочих столов. Рассмотрим теперь устройство рабочего стола на примере достаточно простого рабочего стола «Корпус» программы Анализатор текстов.
В редакторе Вира рабочий стол «Корпус» показан в визуальном редакторе (слева) и в виде схемы (справа):
В этой схеме есть основная изюминка (загвоздка, …) Вира, которую, как я предполагаю, будет сложно принять профессиональными программистами.
В чем сложность?
Во-первых, в том, что мы привыкли рисовать архитектуру (схему) программы в виде плохо определенных прямоугольников и стрелок. Далее, эта схема каким-то образом переводится в программный код и реализация, как правило, не имеет прямого соответствия со схемой. В этом проектирование программы существенно отличается от проектирования электронной схемы или архитектурного сооружения.
Вторая сложность в том, что мир, в котором работает программа, не совсем материалистичен. Попробую это пояснить на примерах.
В электронных схемах есть материальность, включая вещество, из которого сделаны элементы, и что важнее — электричество. Любая часть схемы, к которой не подведено электричество, не работает.
Архитектурные сооружения сделаны из вещества, там работает сила тяжести, сопротивление материалов, необходимость подводки коммуникаций и т.д.
В обоих случаях, изделие, построенное по схеме, работает в материальном мире, этот мир накладывает ограничения, и во многом эти ограничения определяют устройство изделия. Например, здание в виде перевернутой пирамиды построить трудно.
В мире, в котором работает программа, нет привычных ограничений материального мира. Например, программа может обратится в любую часть оперативной памяти с одинаковой легкостью для программиста, пусть и с разной (из-за кэшей) скоростью, но обратится может. Для этого не надо прокладывать проводник или проводить трубу, то есть заранее, при проектировании, закладывать такую возможность (говоря словами анекдота, ОЗУ целиком посыпано мелом).
Отсутствие ограничений есть, с одной стороны, благо, с другой создает предпосылки для непродуманных решений, другими словами, предпосылки к хаотизации программы.
Все мы знаем, что хороший проект может быть испорчен плохой реализацией именно из-за того, что «все можно». Программист думает: почему бы не обратится вот отсюда к той функции, объекту, модулю? Ну и что, что нет стрелочки на схеме, зато это удобно и fast time to market. В итоге, нарисованная архитектура программы через какое-то время не имеет никакого отношения к действительности.
Проблема расхождения архитектуры и реализации программы не нова, и решать её можно разными способами.
Решение Вира – это сделать схему неотъемлемой частью программы, скелетом программы. Как?
Я не зря постоянно использую в примерах электронные схемы. Взглянем на детский электронный конструктор (детский, потому что программирование до сих пор не вышло из детского садика, не правда ли?).
Такой конструктор состоит из контактной площадки с кучей дырочек (разъемов), куда вставляются контакты компонентов и соединительных элементов. Основой (скелетом) любой схемы является контактная площадка.
Точно так же, в Вире рабочий стол строится на основе контактной площадки – «объекта» с универсальными разъемами, к которому можно подключить любой инструмент.
Добавлю, что так как мы собираемся строить системы малость сложнее детских электронных схем, то нам нужна иерархия контактных площадок. Впрочем, она есть и в детском конструкторе, только она спрятана от ребенка внутри черных ящиков, которыми являются электронные компоненты (датчики, моторчики, пищалки и т.д.).
Итак, чтобы построить рабочий стол в Вире мы должны:
- Взять контактную площадку
- Вставить инструменты в разъемы площадки
- А так как часть этих инструментов является контактными площадками (под-площадками), то снова вставить в них инструменты
- И далее рекурсивно, пока не построим всю схему
Конкретней в «следующем номере».