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

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


я не про механизм CRTP, я про идею расширения класса методами (которая может использовать CRTP как средство, но может и иначе).
у авторов boost::operators, на мой взгляд, получилось изящно.

нет, они определяют типы и операции с ними.


т.е. в итоге получается, что базовый интерфейс должен поддерживать операции move, rotate, copy ... и так далее, или должны быть интерфейсы imovable, irotatable, icopyable...
а пользователь сам решает, какие интерфейсы он будет поддерживать. Это приводит нас опять таки к query interface, в том или ином виде.


не совсем представляю как это можно применить к текущей задаче?

Это сообщение отредактировал(а) azesmcar - 11.11.2011, 12:14

видимо я не вполне понял Вашу задачу. прочитал еще раз, внимательно, но нового не увидел.

давайте на примере:
пользователь определил новый тип объекта "пирог" и операцию над ним "съесть"

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

методы определяет фреймворк, пользователи его либо реализуют, либо нет.

Попробую упростить задачу до примера.

Начну с нуля.

Допустим есть библиотека для работы с геометрическими объектами. Библиотека широко используется по всей компании и должна предоставлять возможности для расширения.
Библиотека предоставляет некоторые базовые геометрические типы - полигон, прямоугольник, круг, а также некоторые объекты для разметки, такие как линейка и текст.

Вот иерархия классов:


С объектами можно производить некоторые операции, например копировать или перемещать. Возьмем для примера копирование.
Копирование по сути это текстовая сериализация объекта, далее этот текст помещается в буфер обмена.
Далее.
Группа B используется библиотеку в своем проекте, они добавлают новый тип объектов - точка. Они добавляют свой класс, наследник от figure_base и регистрируют его в библиотеке, далее они должны реализовать копирование объекта типа point.
Теперь о реализации.
Реализовать это можно многими способами, дело в том, чтобы выбрать самый подходящий.

1. Самый тупой способ - поместить все возможные функции в базовый класс figure_base, т.е. поместить туда функцию copy с default реализацией.

если автор класса point добавит в свой класс функцию копирования - тогда все прекрасно, а нет - значит копирование не поддерживается, покажем пользователю фигу.
Но недостаток этого подхода в том, что интерфейс базового класса засоряется.

2. Более цивильный способ, разделить все на интерфейсы, т.е. добавить интерфейс icopyable, imovable... и так далее, а потом проверять, реализует ли класс этот интерфейс с помощью dynamic_cast-а. В итоге получается queryInterface. Недостаток подхода в том, что получается нагромождение всех функций в одном классе, который должен поддерживать и перемещение и копирование и поворот и многое другое. Чем больше функций, тем больше нагромождение, хотя интерфейс базового класса в этом случае не засоряется. Еще один минус подхода в медленной работе самого dynamic_cast-а.

3. С помощью вышеупомянутого шаблона visitor. В принципе все удобно, все разделено по функциональности, надо поменять функцию copy - меняем один класс, можно добавлять функции не меняя интерфейс самих классов. Недостаток в данном случае заключается в том, что при реализации копирование для объектов типа point, программисту придется лезть в нашу библиотеку и менять исходники, что не очень приятно. Желательно, чтобы его расширение было самодостаточно и не требовало модификаций нашего кода.

Надеюсь смог нормально описать.


Это сообщение отредактировал(а) azesmcar - 11.11.2011, 14:25

или таблицы.. 


  , если надо чтоб "визетеры" могли быть динамически расширяемыми..

Добавлено через 3 минуты и 29 секунд

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

Добавлено через 5 минут и 59 секунд

ложить интерфейсы в ядро, это неподъемный труд..  ядро вначале нужно разделить на функционал, а уж каждый функционал можно реализовывать по разному, в том числе и через интерфейсы.. 

Нет, регистрировался не просто класс, а связка его с методом Посетителя - точно не помню как.
Что-то похожее на это (но вряд ли это):

я так и предполагал. тогда достаточно объявить виртуальные методы в базовом классе.


конечно. для решения этой проблемы существует классификация и декомпозиция. 

почитал дальше, вроде разобрался)))

кажется, проблема заключается не в наследовании и операциях, а в том, о чем Вы не упоминаете: операции производятся ядром над объектами базового класса, и нет возможности узнать какие именно интерфейсы реализуются классом.
скажем, end-user выбирает правой кнопкой мыши объект, и контекстное меню должно отобразить доступные операции.
если новые объекты подключаются на этапе компиляции, это можно решить статической проверкой. остальное сделает компилятор. 
если интерфейс нужно определять динамически, то либо callback (эдакие динамические visitorы) либо query-interface. принципиальной разницы в этом случае не вижу.

если я все правильно понял, и речь идет о статической задаче (периода компиляции), то MP (типа is_function_member<>)

Добавлено через 2 минуты и 32 секунды
а статические посетители применяются, если набор операций не предопределен. у Вас это не так

несколько важных моментов упущено.. сейчас попробую выудить их.. 

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

о полиморфности ни слова.. 


динамически добавляют ?

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

Добавлено через 1 минуту и 2 секунды

про АОП читал, но пока его не понимаю, поэтому в этой связи ничего не могу сказать..

Добавлено через 2 минуты и 18 секунд

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

А какие здесь нужны слова?


Нет, статически добавляют и сами же используют. Расширяют библиотеку для своих целей, нас это не касается.


На данный момент я не вижу подходящего решения, чтобы связать с ней задачу 

Добавлено через 1 минуту и 56 секунд

не совсем понял мысль. Почему нет такой возможности? Есть dynamic_cast. На данный момент так и сделано, проверяется реальный тип и вызывается соответствующая функция для этого типа. Цель как раз в том, чтобы избавиться от этого.

Добавлено через 2 минуты и 57 секунд

ну предложите четвертый, мне мои 3 тоже не нравятся  

немножко переформулирую.. 

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

так правильно ?

потом почитаю для интереса, во всяком случае как я понимаю решению задачи это не поможет?

и при добавлении вынуждены перекомпилировать библиотеку ? или ж это не желательно ?



Это сообщение отредактировал(а) mes - 11.11.2011, 15:20

А зачем это нужно? Они же не меняют наших исходников.