Класс-интерфейс

[m_nuhop]

Изначально это была учебная работа, которая включала в себя схожие по структуре классы, назовём их Derived. Каждый класс включал в себя ещё класс (библиотеку), назовем Class. В работе активно использовалось агрегирование (композиция).
Пользователю для работы с классами предоставлялся класс-интерфейс, который включал в себя эти самые классы Derived (опять агрегирование). Для того, чтобы класс-интерфейс понимал, какой класс Derived необходим пользователю, в класс-интерфейс передавался указатель на нужный класс, но с типом void и идентификатор для определения типа класса (числа 1, 2, ..). Класс-интерфейс полученный указатель явно приводил к нужному классу Derived, зная идентификатор типа класса. Отсюда имеем класс-интерфейс с полным доступом к классу Derived. При необходимости класс Derived легко и непринужденно обращался к библиотеке Class и всё это происходило внутри класса-интерфейса. Так был достигнут нехилый динамизм.

Со временем код рос, число классов Derived увеличивалось и класс-интерфейс приходится модифицировать, но с сохранением имеющегося функционала.

Выбор наследования от базового класса упирается в потерю гибкости, потому что присваивание, приведение или копирование Base* = Derived* приводит к срезке и полученный Base* - это уже не тот Derived*.
Использование библиотеки boost, что позволяет создавать контейнеры с разными типами классов, пока не рассматривается.

Я не большой мастак объяснять, но ... пианист играет, как умеет.
Есть ли идеи для решения такой задачи?

[Igor95]

Думаю нужно рассмотреть вариант создания интерфейса, элемент которого имел бы сигнатуру - тип соответсвующего класса для выполнения некой опреации.
Например, char* GetEmployeeAddress(Derived*);
Я хочу сказать, что все классы вашей иерархии предоставляют некий функционал.
Вы пытаетесь, насколько я понял, предоставить доступ к этому функционалу используя класс-интефейс.
Тогда почему бы не определить интерфейс, элементы которого выполняли бы определенные операции С ПОМОЩЬЮ других классов.

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

[waleri]

Сообщение от m_nuhop

Выбор наследования от базового класса упирается в потерю гибкости, потому что присваивание, приведение или копирование Base* = Derived* приводит к срезке и полученный Base* - это уже не тот Derived*.

Потеря гибкости и так уже есть - все ограничено методами внешнего "универсального" класса. В чем тогда разница, если этот "универсальный" класс будет базовым интерфейсом для всех Derived классов?

Сообщение от m_nuhop

Есть ли идеи для решения такой задачи?

Это не задача, это метод решение какойто другой задачи. Вопрос в том, какова была изначальная задача - возможно есть лучший вариант решения, чем "универсальный" интерфейс.

[_Bers]

Сообщение от m_nuhop

библиотеке Class и всё это происходило внутри класса-интерфейса. Так был достигнут нехилый динамизм.

Говнокод. Автору кода - выбросить его в мусорку.
И впредь, прежде чем пилить фичу ради фичи, подумать: как он собирается это использовать. И только потом думать о реализации.

Это трудно даже назвать ООП головного мозга. Это просто каша.

[rrrFer]

Использование библиотеки boost, что позволяет создавать контейнеры с разными типами классов, пока не рассматривается.

Да что тебе даст контейнер с разными типами объектов?
Я уже 2 раза спрашивал как ты собираешься с этим работать.
Извлек ты элемент из контейнера и не знаешь что с ним можно делать, а что нельзя и перед тем как с ним работать ты по-любому напишешь что-то типа dynamic_cast, но беда в том, что ты будешь делать это 15 раз и постоянно.

[m_nuhop]

Думаю нужно рассмотреть вариант создания интерфейса, элемент которого имел бы сигнатуру - тип соответсвующего класса для выполнения некой опреации.
Например, char* GetEmployeeAddress(Derived*);

Можно ли здесь остановиться поподробнее? Можно ли получить детали реализации?

Я хочу сказать, что все классы вашей иерархии предоставляют некий функционал.

Да, именно так. Получаем множество разных функционалов.

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

Да, класс-интефейс - это некий контроль доступа к разным функционалам.

Тогда почему бы не определить интерфейс, элементы которого выполняли бы определенные операции С ПОМОЩЬЮ других классов.

Я не знаю, как это сделать. Можно ли получить детали реализации?

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

Мир несовершенен. Допущенные и упомянутые здесь нарушения ООП и т.д. были сделаны умышленно, потому что так мне удобнее.

[Igor95]

class Interface
{
public:
//interface
_returnval SomeMethod(Derived*);
_returnval SomeMethod(Derived*);
//и так далее
//...
};
Ваш подход

Мир несовершенен. Допущенные и упомянутые здесь нарушения ООП и т.д. были сделаны умышленно, потому что так мне удобнее.

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

Мне кажется, что ни один из квалифицированных разработчиков ПО даже не стал бы смотреть на код, в котором нарушена инкапсуляция.