OberonCore

Уже много раз обсуждались эти вещи, но по отдельности. А вот если их поставить рядом и оценить с точки зрения контура управления, то что получится?

Можно ли говорить в том смысле, что хуки требуются для встраивания в изолированный процесс управления извне, а шина даёт возможность встраиваться как бы "внутрь"? (извините за такие формулировочки, по-другому пока никак). Как оно в теории?

Обратите внимание, Иван, что хуки в отличие от каталогов инсталлируемых объектов (Directory) используются исключительно в том же интерфейсном модуле (сервере), в котором они объявлены. А экспортируются лишь процедуры, которые используют эти хуки. В этом, на мой взгляд, основное отличие Hook и Directory.
А общее у них то, что и те и другие требуют инсталляции.

Да, всё так. Меня интересует вопрос архитектурного выбора.

Архитектурный выбор следует из того, что я сказал.

Если дополнительные функции, требующие скрытой реализации и инсталляции, нужны только самому модулю-серверу (то есть это его внутренняя кухня), то используют Hook.
Если дополнительные функции, требующие скрытой реализации и инсталляции, должны быть доступны модулям-клиентам, то используют Directory. В этом случае модуль-сервер экспортирует точку доступа VAR dir-: Directory, чего не наблюдается в случае с хуками.

Если я опять ответил не то, то сформулируйте, пожалуйста, вопрос точнее

Причём тут фабрики? Вопрос был в противопоставлении шины сообщений и инсталлируемого хука.

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

UPD. Ну и, придётся описывать кучу сообщений, чтобы полностью описать реакции системы.

UPD2. Кстати, в некоторых случаях можно применить развитие хука - нечто, напоминающее по смыслу "владельца"(не знаю, как называется, owner, context типа того). Некая компонента для себя определяет управляющую и контроллирующую структуру(пока всё так же, как и в хуке) но мы потом эту структуру развиваем до уровня обычного объекта(с методами, с полями итд). И при необходимости инкапсулируем изначальную структуру. Тогда нет нужды переносить контекст(потому что он и так на месте).

Извиняюсь Как раз с этим работал. Не переключил контекст задачи. Хочется успеть и тут и там, а получилось "как всегда".
За двумя зайцами погонишься -- от обоих <...> получишь!

Я задавал вопрос несколько из другой позиции, ещё раз прошу прощения за неудачную передачу смысла.
Такие проектные решения, как хуки, фабрики или шины выбираются, исходя из задачи. Иногда случается так, что неправильно принимаешь решение и применяешь тот или иной вариант, но не слишком удачно. Я не силён в теории систем, поэтому могу лишь предполагать, что, например, хуки и шина работают в разных контурах управления.
Отсюда и вытекает интерес к рассмотрению архитектурных элементов в единой системе отсчёта.

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

Хуки -- развитие идеи разделения интерфейса и реализации в сторону динамики, чтобы менять реализацию на лету. Это понятно. Для бутстрапа, например.

Шина сообщений, on the other hand, -- способ общаться, скажем, модулям, без знания всей (динамической) цепочки посредников, и даже без знания структуры этой цепочки. Может быть, в этом и суть -- в абстрагировании даже от структуры этой связи. Как и численности аудитории общения.

На эту тему Гамма и др. много слов, конечно, сказали. Но у них смысл не отжат. И не причесан.

Нельзя. Извне - это откуда, а внутрь - это куда. Если сопоставлять - то по одному критерию.

Да, наверное, мой вопрос именно отсюда.


Приведу условную аналогию с паровозом, может моя мысль вылезет из этих трёх сосен

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

А шина сообщений, по-моему, является информационным каналом между, например, машинистом, и модулями подачи сигнала, изменения скорости и другими. Подменяя хуки, мы даём новую реализацию, подключенную тем же к каналам управления старым способом.

Под "встраиванием внутрь" я имел в виду обработку сообщений. По сути, это более гибкое изменение поведения, потому что в отличие от жестко заданного интерфейса хука, у нас сигналы для модуля поступают по универсальному каналу. Такой локомотив имел бы в кабине один-единственный рупор, куда машинист кричал бы команды: "свистнуть", "увеличить скорость" и т.п.

> Хуки или шина

Почему или?
По хукам тоже можно сообщения прокачивать.

Проще будет не пояснять что именно имели в виду, а отредактировать исходное высказывание, вероятно.
Один и единственный это одно и то же.

Да, тогда их можно рассматривать как информационный канал, то есть - шину.
Если проще, я бы так и поступил.
Это общеупотребительная идиома, вообще-то.

И я. А в чем проблема с редактированием?
Вполне возможно, но, на мой взгляд, смысл моего высказывания от этого не изменяется.

У Вас проблемы с редактированием? У меня - нет.
Просто высказывание Ваше ни к селу, ни к городу, уж извините

Прошу разъяснить термин "родовая шина сообщений". Часто встречается, пока не понимаю.

Кстати, действительно. Почему "родовая", когда в generic message bus -- generic относится к message (в котором, кстати, нейтрализовано множественное число).
Смысл тут: шина для некоторого класса сообщений.

Перевод неудачный, а повелось с вологодского сайта, кажется.