Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Я тут как-то исследовал эволюцию базового/внутреннего интерфейса для всех своих программ. Когда-то решил, что достаточно add_ref/release, а вместо QueryInterface вполне сгодится dynamic_cast.
Блог интересный, мне понравилось! Пиши ещё!

Есть места, на которые любуешься
Абстрактный базовый класс (aka interface) — великолепно! Применение шаблонов (templates) — гениально!
И самое важное — когда доходишь до этого всего своим умом, а не просто вычитываешь в толковой кижице


КД>Но к концу второго десятка лет непрерывного развития своей "игрушки" пришел к выводу, что query_interface таки придется прикручивать к внутренним интерфейсам (которые наружу никогда не будут выставлены).
Есть принцип KISS — зачем же нам здесь его нарушать?
Внутренний интерфейс — что за зверь?
Если можно — может есть подходящий паттерн проектирования?

КД>---
КД>UPD. Самое смешное, что когда программировал одну хреновину под .NET (куча классов с IDispose), тоже пришлось к ним прикручивать старый добрый COM счетчики. Только там это были не счетчики ссылок, а счетчики активных вызовов методов.

P.S. Самое главное, ИМХО — осознавать ситуации, когда стреляем пушками по воробьям
Каждая проблема всегда имеет адекватное решение...
Можно придумывать решение "универсальной" проблемы, при этом плодить массу разных сложностей.
Тот же QueryInterface:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682521(v=vs.85).aspx
Он хороший, когда тиражируем различные компоненты (читай: COM компоненты) сотнями тысяч, а разновидностей их интерфейсов — около тысячи.
Если у меня количество компонентов можно пересчитать по пальцам (одной руки), а количество интерфейсов — хорошо, если пару штук, то
применение dynamic_cast<...>(...) вместо QueryInterface — заметно упрощает жизнь...

Здравствуйте, Коваленко Дмитрий, Вы писали:

КД>Я тут как-то исследовал эволюцию базового/внутреннего интерфейса для всех своих программ. Когда-то решил, что достаточно add_ref/release, а вместо QueryInterface вполне сгодится dynamic_cast.
Блог интересный, мне понравилось! Пиши ещё!

Есть места, на которые любуешься
Абстрактный базовый класс (aka interface) — великолепно! Применение шаблонов (templates) — гениально!
И самое важное — когда доходишь до этого всего своим умом, а не просто вычитываешь в толковой кижице


КД>Но к концу второго десятка лет непрерывного развития своей "игрушки" пришел к выводу, что query_interface таки придется прикручивать к внутренним интерфейсам (которые наружу никогда не будут выставлены).
Есть принцип KISS — зачем же нам здесь его нарушать?
Внутренний интерфейс — что за зверь?
Если можно — может есть подходящий паттерн проектирования?

КД>---
КД>UPD. Самое смешное, что когда программировал одну хреновину под .NET (куча классов с IDispose), тоже пришлось к ним прикручивать старый добрый COM счетчики. Только там это были не счетчики ссылок, а счетчики активных вызовов методов.

P.S. Самое главное, ИМХО — осознавать ситуации, когда стреляем пушками по воробьям
Каждая проблема всегда имеет адекватное решение...
Можно придумывать решение "универсальной" проблемы, при этом плодить массу разных сложностей.
Тот же QueryInterface:
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682521(v=vs.85).aspx
Он хороший, когда тиражируем различные компоненты (читай: COM компоненты) сотнями тысяч, а разновидностей их интерфейсов — около тысячи.
Если у меня количество компонентов можно пересчитать по пальцам (одной руки), а количество интерфейсов — хорошо, если пару штук, то
применение dynamic_cast<...>(...) вместо QueryInterface — заметно упрощает жизнь!

P.P.S. Просто задачи, решаемые как нашим приложением, так и его плагинной подсистемой, достаточно специфичны...