[шаблоны] Посоветуйте, можно ли улучшить код

[kuzulis]

Да, спс, точно, компилится (по крайней мере на винде)..

[__Heaven__]

Под g++ и clang тоже компилится

[Igors]

Код

C++ (Qt)
class IManager{
..
class AbstractManager: public QObject, public IManager{
..
template<class T>
class ElementManager: public AbstractManager{
..
 

Как-то дороговато достигается пресловутая "общность". Конечно в этих 3 классах нет ничего сложного, но это все-таки уже 3 класса.

И виртуальный doSomething обычно не устраивает, это дела конкретной инстансы

[__Heaven__]

В чём дороговизна? Количество классов? А чем это мешает?
Например, в использовании QTreeView разве мешает его наследование от QTreeView, QAbstractItemView, QAbstractScrollArea, QFrame, QWidget, QObject, QPaintDevice?

И виртуальный doSomething обычно не устраивает, это дела конкретной инстансы

Я не понял, что здесь написано

[Igors]

В чём дороговизна? Количество классов? А чем это мешает?
Например, в использовании QTreeView разве мешает его наследование от QTreeView, QAbstractItemView, QAbstractScrollArea, QFrame, QWidget, QObject, QPaintDevice?

А могут ли Ваши IManager, AbstractManager, ElementManager претендовать на ту же капитальность/фундаментальность? Оправдывают ли они время что нужно затратить на знакомство с ними?

И виртуальный doSomething обычно не устраивает, это дела конкретной инстансы

Я не понял, что здесь написано

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

[__Heaven__]

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

Пускай расходятся, я не против. Функционал будет расширяться невиртуальными методами.

А виртуалом можно поддержать только общую для всех операцию

Виртуал здесь выделен по той причине, что из шапки видно, что ТС хочет иметь некий метод do_Something в каждом экземпляре менеджера. Также видно, что он хочет возвращать указатели на менеджеров. Я предположил, что возможно он, захочет ещё держать менеджеров в неком контейнере и в цикле вызывать у каждого do_Something.

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

Вы с QPaintDevice знакомились от и до перед тем как использовать QWidget? Также если я хочу досконально знакомиться с классом, то я быстрее познакомлюсь с классом в 50 строк, чем с монстром в 1000.

капитальность/фундаментальность

Опять не понимаю.

[Igors]

капитальность/фундаментальность

Опять не понимаю.

Знакомиться с  QTreeView, QAbstractItemView, QAbstractScrollArea, QFrame, QWidget, QObject, QPaintDevice все равно так или иначе придется, причем это можно делать постепенно. почитывая букварь от случая к случаю. Понадобилось что-то - освоил, а "надобится" постоянно.

А вот с самопальными классами ситуация другая. Это совсем не претензия к Вам лично, ситуация очень типовая. Да, часто можно добиться желаемого, но.. стоит ли оно того? Достаточно ли много достигается 3-мя классами? Может можно было обойтись одним? Не исключено что вообще никакие template здесь не нужны - тупо продублить код для 10 менеджеров. Пока общего ф-ционала с гулькин нос (add и delete) - почему нет? Тут часто говорят "а если.." - да, но часто никаких расширений не происходит (ну вот не растет проект в эту степь), и излишняя/дутая общность оседает мертвым грузом

[__Heaven__]

тупо продублить код для 10 менеджеров

Потом тупо исправить ошибку в 9 из них и тупо забыть исправить в 10. Затем понять, что надо немножко расширить функционал и снова тупо копипастить. А потом мы в менеджере №3 захотим метод сортировки наоборот, а в менеджере 8 возможность общаться с себе подобными. И, конечно, будет куда проще разобраться в этих 10 классах, чем в одном шаблоне.

с самопальными классами ситуация другая

Чем же она другая? Никто не запрещает пользоваться классом ElementManager не зная внутреннего строения AbstractManager. Точно также, никто не запрещает постепенно осваивать AbstractManager.

Может можно было обойтись одним

Конечно можно. А ещё можно обойтись процедурным программированием в едином main.cpp или ассемблером.
Повторю, что на мой взгляд, понять устройство маленького класса значительно проще. Помимо этого здесь есть преимущество в скорости компиляции. Не всегда требуется инклудом тащить толстый класс (а может и не один). Достаточно взять интерфейс и через него вызывать необходимые виртуальные методы. Мне кажется, что вам эти преимущества уже не один раз разъясняли и вы вновь занимаетесь флудом в сторонней теме.

Пока общего ф-ционала с гулькин нос (add и delete) - почему нет?

Потому что ТС писал

не буду же я рисовать здесь всю подноготную

Наверняка класс будет претерпевать расширение.

излишняя/дутая общность оседает мертвым грузом

А про классы без использования шаблонов вы случаем не скажете того же самого?

2 kuzulis, а вы не рассматривали вариант использования QMap<IdType, ValueType> ?

[kuzulis]

2 kuzulis, а вы не рассматривали вариант использования QMap<IdType, ValueType> ?

Не, сейчас все устраивает.. правда я слепил IManager + AbstractManager в один класс... т.о. у меня только две реализации: QObject-овая и шаблонная..  

[Igors]

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

Да, может быть и так

А потом мы в менеджере №3 захотим метод сортировки наоборот, а в менеджере 8 возможность общаться с себе подобными. И, конечно, будет куда проще разобраться в этих 10 классах, чем в одном шаблоне.

А здесь неясно. Если 10 совершенно независимых классов - у меня никаких проблем с сортировкой наоборот в менеджере №3. А вот если укладывать их в общую конструкцию - придется пыхтеть с обобщением.

И, конечно, будет куда проще разобраться в этих 10 классах, чем в одном шаблоне.

Не исключено что и легче. Напр можно записать

Код

C++ (Qt)
manager.addMyObject();
// вместо безликого 
manager.addElement();
 

И это может оказаться лучше (или приятнее) экономии с template

Чем же она другая? Никто не запрещает пользоваться классом ElementManager не зная внутреннего строения AbstractManager. Точно также, никто не запрещает постепенно осваивать AbstractManager.

Ну это вряд ли  

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

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

[__Heaven__]

А потом мы в менеджере №3 захотим метод сортировки наоборот, а в менеджере 8 возможность общаться с себе подобными. И, конечно, будет куда проще разобраться в этих 10 классах, чем в одном шаблоне.

А здесь неясно. Если 10 совершенно независимых классов - у меня никаких проблем с сортировкой наоборот в менеджере №3. А вот если укладывать их в общую конструкцию - придется пыхтеть с обобщением.

Код

C++ (Qt)
class DescSortIntManager: public ElementManager<int>{
    void sort();
}
 

[Akon]

ИМХО, видится такая реализация:

- менеджер - елементы: независимо от типов обоих, уже есть что-то общее (добавить/удалить и т.п.), поэтому делаются базовые нешаблонные классы Manager, Element. В этих классах декларируются сигналы added(Element*)/removed(Element*) и т.п. Естественно, для обеспечения полиморфизма здесь используются только указатели Manager*, Element* (или смарт-указатели).

- далее для типобезопасности используются тонкие шаблонные обертки, выполняющие downcast.

В результате, нет "раздутия" кода из-за шаблонов, и есть типобезопасность.