Нужна помощь в создание иерархтии объектов

Надеюсь идея понятна.

Только твоим дружкам-грибам.

Шаблоны хороши как раз тем, что не вносят требований типа «все объекты наследуются от Obj».

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

Надеюсь идея понятна.

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

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

Т.е. шаблон лучше чем абстрактный класс в роли родителя для всех менеджеров?

Если подробнее, то я хотел бы сделать абстрактный класс(предок всех менеджеров), но не знаю как быть с полем objs.
Сначала хотел опустить его, тем самым подразумевая добавление поля в классах-наследниках(естественно снабдив предупредительным комментарием). Но побоялся, что на это будут плевать и имена пойдут в разнобой, что может ухудшить читаемость кода.
Затем решил создать шаблон, но не знал как правильно его реализовать.
Не знал как разрулить ту ситуацию, что одни контейнеры принимают один параметр, другие 2, ну и вдруг кому пригодиться запилить свой велосипед или еще чего. По этому я склоняюсь к супер-предку от которого можно и шаблоны строить и седьмую воду на киселе.
Может где опять туго выразился или неверен ход мысли говорите.
Буду рад услышать конструктивную критику.

Еще раз спасибо всем, кто откликнулся.

Мне это самому не нравится. Я думал много о том, как все это правильно реализовать но пока в голову приходят только эти нагромождения.

но пока в голову приходят только эти нагромождения.

Про делегирование благородный дон, по ходу, не слышал. Исходная задача то какая, проэктировщег?

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

Сразу видно опытного программиста и архитектора, одного уровня с Фаулером, Бучем, Блохом.

Наследование - сильная связь, сильнее только дружба. Сильных связей лучше избегать.

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

Единый предок для таких вещей скорее не будет содержать реализации вообще, учитывая отличия контейнеров. А общий интерфейс будет очень ограниченным; различия в доступе к данным будет тому причиной. Можно извратиться и поместить разные типы данных в базовый класс на шаблонах, но его инстансы будут иметь различные типы для каждого типа данных, а значит не будут взаимозаменяемыми. Так что это не имеет большого смысла. Если посмотреть на те же коллекции в Java, то там для разных групп контейнеров различные интерфейсы (List, Map), просто потому что свести их в один общий получится с трудом (интерфейс Collection тому пример, он очень ограничен по своим возможностям).

Как указали другие отвечающие, лучше проанализировать решаемую задачу ещё раз и не пытаться изобрести универсальное решение. Если разработка такой иерархии это попытка использовать все контейнеры единым образом, то это не совсем в стиле C++. «C++ way» будет определить шаблонные функции-алгоритмы для обработки контейнеров любого типа (с которыми работать только через итераторы). Если есть и другие причины, то иерархия коллекций Java может быть хорошим примером (разработать лучше врятли получится).

Спасибо, почитаю про устройство коллекций.

А чем диаграммы нарисованы?

freemind

Чувак, осиль UML же.

карандашом от руки а листок видно был у соседа на спине

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