Арвиль: вглядываясь в бездну

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

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

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

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

В-третьих, Вир — это инструмент сборочного программирования и это близко к архитектурному программированию, но это взгляд с другой стороны зеркального стекла. Для сборки важны:

  • детали, которые можно соединить
  • и способы их соединения

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

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

Это разделение скорее философское, но из него есть и практические следствия.

Например, о необходимости материального воплощения архитектуры (каркаса), которая, как я вижу, (почти всегда) является деревом (скорее, деревом деревьев). Вопрос о том, нужно ли использовать ациклические графы вместо деревьев для меня является открытым.

Узел дерева в Вире назывался «стол». Сейчас я предпочитаю термин «верстак» (рабочее место с инструментами — арками). Верстак задает структуру и отвечает за жизненный цикл и взаимодействие.

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

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

 

 

1 комментарий


  1. ИМХО, нельзя от дереева переходить к графам — это портит всю идею, как мне кажется. А идея эта — в переносе отношения «часть-целое» из мира 3D-объектов (и соответствующих навыков системного мышления, и многих методов анализа, проектирования, измерения) в мир software design, где все гибче, и как раз не хватает жесткости и высокоуровневых структур.

    Только если мы вводим явное и четкое отношение «А — есть часть Б», мы включаем новое мышление. Но если А — это часть Б, то оно никак не может быть частью С, если С — не часть А. Т.е. дерево, а не какой-то более произвольный граф

    Ответить

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *