OberonCore
https://forum.oberoncore.ru/

Хуки
https://forum.oberoncore.ru/viewtopic.php?f=2&t=681
Страница 1 из 1

Автор:  Иван Кузьмицкий [ Вторник, 09 Октябрь, 2007 11:56 ]
Заголовок сообщения:  Хуки

Что есть хуки в Ящике и какую роль они выполняют?

Например, генератор диалоговой формы FormGen.Create вызывает процедуру Views.Open(v, loc, name, NIL) для открытия отображения в отдельнном окне, а та, в свою очередь, обращается к методу viewHook.Open. Переменная viewHook имеет абстрактный тип ViewHook, с абстрактными же методами, которые реализуются в StdDialog, там же и создаётся экземпляр viewHook.

Ещё, на форуме "Мысли об Обероне" есть такое сообщение двухлетней давности:

Цитата:
№ 2355 04-07-2005 07:09

А на счет "волшебного" Kernel.Hook из Oberon microsystems AG отписали, что это не баг, а фича :) :
...
types which extend Kernel.Hook are a configuration mechanism intended to be used only by framework programmers. "Normal" BlackBox clients should neither use nor see hooks. That's why DevBrowser masks them out.

Cheers
Marc,
Oberon microsystems AG

(Собс-но, в этом и причина, почему хуки не показываются в интерфейсе, в обычном режиме.)

Интересует именно архитектурное назначение хуков, почему именно хуки, и почему именно так?

Автор:  Илья Ермаков [ Вторник, 09 Октябрь, 2007 12:08 ]
Заголовок сообщения:  Re: Хуки

Хук - это объектно-ориентированный разъём между модулями. Модуль реализации подключает этот разъём к интерфейсному модулю. Подробнее объяснено в http://oberoncore.ru/download/articles/DesignIdeas.pdf . Проще говоря, это вариация из той же оперы, что и Directories - для разделения интерфейса и конкретных реализаций.

Автор:  Иван Кузьмицкий [ Вторник, 09 Октябрь, 2007 12:27 ]
Заголовок сообщения:  Re: Хуки

Илья Ермаков писал(а):
Хук - это объектно-ориентированный разъём между модулями. Модуль реализации подключает этот разъём к интерфейсному модулю. Подробнее объяснено в http://oberoncore.ru/download/articles/DesignIdeas.pdf . Проще говоря, это вариация из той же оперы, что и Directories - для разделения интерфейса и конкретных реализаций.


Илья, спасибо за ответ!
Насколько я понимаю, директория - это "фабрика", в терминах OO Patterns. Хук как разьём... Да, век живи — век учись :) Перечитываю DesignIdeas под другим углом зрения :)

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

Ой, не зря BlackBox носит такое название. Идеологическое название, а эта идеология прослеживается ну просто повсюду.

Автор:  Илья Ермаков [ Вторник, 09 Октябрь, 2007 12:50 ]
Заголовок сообщения:  Re: Хуки

Иван, Вы нашли красивое толкование Hook! Спасибо за идею! :-)
У Вас, видимо, мозги не запорошены WinApi, потому что я до сего момента считал название Hook (трактуя его как "перехватчик") неудачным :-)

Автор:  Иван Кузьмицкий [ Вторник, 09 Октябрь, 2007 13:32 ]
Заголовок сообщения:  Re: Хуки

Илья Ермаков писал(а):
Иван, Вы нашли красивое толкование Hook! Спасибо за идею! :-)
У Вас, видимо, мозги не запорошены WinApi, потому что я до сего момента считал название Hook (трактуя его как "перехватчик") неудачным :-)


А ещё есть перевод "ловушка", в документации к модулю DevBrowser. Заглянул в словарь, у слова Hook много толкований, есть и "гак, захватка, зацепка", близко к перехвату. Но большинство значений из словаря (Lingvo) описывают вот это вот "одностороннее взаимодействие", ну или как ещё назвать зацепление чего-то кем-то с проявлением активности\пассивности.
Почитал про перехваты в WinApi, там же вроде бы замещение системных функций своими, то есть "перехват" обращения, перехват вызова. Только почему-то речь идёт о "перехвате функции", "обходе" (detour) и "трамплине" (trampoline). По мне, так это неаккуратное обращение с языком, с понятийным аппаратом и произвольное подтягивание понятий.
Другое дело, hooks in the BlackBox. Слово не расходится с делом, образы соответствуют описанию - компоненты, ящики, а ящики можно крюками цеплять друг к другу :)

Автор:  CheshireCat [ Пятница, 12 Октябрь, 2007 04:07 ]
Заголовок сообщения:  Re: Хуки

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

Автор:  Иван Кузьмицкий [ Пятница, 12 Октябрь, 2007 09:21 ]
Заголовок сообщения:  Re: Хуки

CheshireCat писал(а):
...Но реально все равно ООП оказывается не способно обеспечить все
нужные на практике разновидности расширяемости. И тем более не
способно полностью поддержать все виды _модифицирования_ проекта
(поскольку _урезание_ все равно не поддерживается).


Чисто для расширения моего кругозора попросил бы Вас перечислить все разновидности расширяемости и виды модифицирования проекта. Такая классификация очень полезна.

Автор:  Илья Ермаков [ Пятница, 12 Октябрь, 2007 12:10 ]
Заголовок сообщения:  Re: Хуки

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

Автор:  CheshireCat [ Среда, 17 Октябрь, 2007 10:05 ]
Заголовок сообщения:  Re: Хуки

Цитата:
Чисто для расширения моего кругозора попросил бы Вас перечислить все разновидности расширяемости и виды модифицирования проекта. Такая классификация очень полезна.

а нету одновременно и полной и общепринятой)) сейчас общепринято всюду совать ООП. которое позволяет лишь расширять некоторые заранее предназначенные для этого части программы. но для этого надо заранее запланировать в архитектуре все возможные направления модификации. и потом говорят придется только добавлять код. в реальности оказывается)) что иногда кое-что нельзя было предвидеть при проектировании и как следствие возникает проблема "хрупких базовых классов" - часть системы уже нельзя изменить потому что развалится хитро зависящая от ее особенностей часть. и зависимостей если повсюду совать ООП будет мноого))
А для классификации... ну попробуйте например для начала представить себе морфологический ящик комбинаций расширений-сохранений-УРЕЗАНИЙ пары модульсервис-модульклиент... и пометьте галочками какие из 9 вариантов поддержит ООП... и почему нужны хуки...

Автор:  Иван Кузьмицкий [ Среда, 17 Октябрь, 2007 12:12 ]
Заголовок сообщения:  Re: Хуки

CheshireCat писал(а):
Цитата:
Чисто для расширения моего кругозора попросил бы Вас перечислить все разновидности расширяемости и виды модифицирования проекта. Такая классификация очень полезна.

а нету одновременно и полной и общепринятой)) сейчас общепринято всюду совать ООП. которое позволяет лишь расширять некоторые заранее предназначенные для этого части программы. но для этого надо заранее запланировать в архитектуре все возможные направления модификации. и потом говорят придется только добавлять код. в реальности оказывается)) что иногда кое-что нельзя было предвидеть при проектировании и как следствие возникает проблема "хрупких базовых классов" - часть системы уже нельзя изменить потому что развалится хитро зависящая от ее особенностей часть. и зависимостей если повсюду совать ООП будет мноого))
А для классификации... ну попробуйте например для начала представить себе морфологический ящик комбинаций расширений-сохранений-УРЕЗАНИЙ пары модульсервис-модульклиент... и пометьте галочками какие из 9 вариантов поддержит ООП... и почему нужны хуки...


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

Так что в природе кое-что есть, это просто я не в курсе :)

Автор:  Илья Ермаков [ Среда, 17 Октябрь, 2007 12:24 ]
Заголовок сообщения:  Re: Хуки

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

Автор:  Борис Рюмшин [ Среда, 17 Октябрь, 2007 16:47 ]
Заголовок сообщения:  Re: Хуки

Илья Ермаков писал(а):
...прямо как НДС... Надо вводить Налог на Добавленную Сложность)

Батенька, бухгалтерия на вас плохо влияет. Пора завязывать. :mrgreen:

Автор:  Илья Ермаков [ Среда, 17 Октябрь, 2007 20:02 ]
Заголовок сообщения:  Re: Хуки

Вот разберусь... И завяжу :-)

Страница 1 из 1 Часовой пояс: UTC + 3 часа
Powered by phpBB® Forum Software © phpBB Group
https://www.phpbb.com/