Я начал практически разбирать большой клубок вопросов, связанных с созданием арок, жизненного цикла и взаимодействием между ними.
Вчера я несколько часов вглядывался в Вир, чтобы вспомнить, как это делалось там (к счастью, никто не начал вглядываться в ответ). Увы, напрямую использовать решения из Вира невозможно.
Во-первых, Вир активно развивался несколько лет (археологические раскопки показывают наличие нескольких культурных слоев). Причем, в программе, сделанной в Вире, могут использоваться инструменты, сделанные с использованием разных подходов, и не все подходы надо сейчас брать. Нужно разделять и критически оценивать каждое решение.
Во-вторых, обоснованием решения в Вире часто было — «работает, значит, хорошо». Разработка Вира была захватывающим приключением, и мне часто не хватало времени и желания для того, чтобы остановиться, сравнить несколько решений и выбрать лучшее. Очень может быть, что какое-то решение является лучшим, но сейчас я хочу большей осознанности в выборе.
В-третьих, Вир — это инструмент сборочного программирования и это близко к архитектурному программированию, но это взгляд с другой стороны зеркального стекла. Для сборки важны:
- детали, которые можно соединить
- и способы их соединения
А то, что при этом в программе есть некий каркас (материнская плата), к которому присоединяются детали, является полезным, но не обязательным — почему бы деталям не соединяться напрямую?
Для архитектурного программирования, наоборот, важна архитектура — обязательный каркас. Детали тоже важны, но они вторичны.
Это разделение скорее философское, но из него есть и практические следствия.
Например, о необходимости материального воплощения архитектуры (каркаса), которая, как я вижу, (почти всегда) является деревом (скорее, деревом деревьев). Вопрос о том, нужно ли использовать ациклические графы вместо деревьев для меня является открытым.
Узел дерева в Вире назывался «стол». Сейчас я предпочитаю термин «верстак» (рабочее место с инструментами — арками). Верстак задает структуру и отвечает за жизненный цикл и взаимодействие.
Если посмотреть в исходники: арки и верстак, то видно, что есть Верстак — это протокол, описывающий поведение верстака и арка, реализующая этот протокол. Реализация может быть (и будет не единственной).
Протокол пока совсем черновой, всего несколько функций, в нем пока есть только маленький кусочек жизненного цикла и начало работы с уведомлениями. Напишу подробнее, когда жизненный цикл меня додумает.
Постоянная ссылка
ИМХО, нельзя от дереева переходить к графам — это портит всю идею, как мне кажется. А идея эта — в переносе отношения «часть-целое» из мира 3D-объектов (и соответствующих навыков системного мышления, и многих методов анализа, проектирования, измерения) в мир software design, где все гибче, и как раз не хватает жесткости и высокоуровневых структур.
Только если мы вводим явное и четкое отношение «А — есть часть Б», мы включаем новое мышление. Но если А — это часть Б, то оно никак не может быть частью С, если С — не часть А. Т.е. дерево, а не какой-то более произвольный граф