Агрегация по указателю или агрегация объекта

[blood_shadow]

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

Диалог можно сделать 3 способами: множественным наследованием, агрегацией с помощью указателя
и просто агрегацией объекта

Код

C++ (Qt)
class MyDialog : public QDialog, public Ui::myDialog
{}
 
...
 
class MyDialog : public QDialog
{
Ui::Dialog *ui;
}
 
MyDialog::MyDialog()
: ui(new Ui::myDialog)
 
...
 
class MyDialog : public QDialog
{
Ui::Dialog ui;
}
 
 

Понятно что множественное наследование здесь вариант хуже всего, да и вообще
множественное наследование редко когда сулит что-нибудь хорошее,

а вот вопрос именно про 2 последних варианта, в первом случае наш объект формы будет
жить в куче, а во втором на стеке, хотелось бы услышать мнение экспертов каков вариант
лучше и какие есть +/- двух последних

Спасибо 

[alexman]

2 и 3 мало чем отличаются, так как в форме все равно указатели хранятся.

[kambala]

тоже всегда интересовал этот вопрос применимо к UI в Qt - нигде не написано что и когда лучше использовать, а спросить как-то стеснялся

минус агрегации через указатель - надо писать delete в деструкторе и new в конструкторе (лишние символы) потому всегда пользуюсь "просто" агрегацией.

[blood_shadow]

тоже всегда интересовал этот вопрос применимо к UI в Qt - нигде не написано что и когда лучше использовать, а спросить как-то стеснялся

та тут все свои нечего стеснятся 

минус агрегации через указатель - надо писать delete в деструкторе и new в конструкторе (лишние символы) потому всегда пользуюсь "просто" агрегацией.

я тож так делаю

[Akon]

В общем случае вариан с указателем более гибкий:
- позволительно forward declaration (т.е. меньше зависимостей времени компиляции);
- есть возможность хранить агрегаты полиморфных типов (паттерн стратегия);
- полный контроль над временем жизни агрегата (создание и удаление в любое время); в частности, очень распространена lazy initialization;
- в случаях, где это имеет смысл, можно использовать shared-агрегаты.

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

Вариант с множественным наследованием, но только с закрытым (наследование реализации), близок варианту с объектом-членом, но имеет "потенциальные проблемы множественного наследования". Если таких проблем не предвидится, возможно, следует использовать его по причине меньшего синтаксиса (в ущерб читаемости).

В литературе под тем, что вы обозначили агрегацией, используется термин композиция (composition - закрашенный ромб в UML). Агрегация - это когда агрегируемые объекты не уничтожаются владельцем. В русском переводе GoF агрегация именуется "отношением осведомленности".

[Igors]

В данном случае "без разницы", экономия на написании неск строк несущественна. В любом случае "Ui" всецело принадлежит диалогу. Не видно реальных вариантов когда член Ui может передаваться "из рук в руки", совместно использоваться, быть полиморфным и.т.п. (здесь хорош указатель). Множ наследование, на мой взгляд, ничем здесь не плохо, пожалуй даже "самое идейное". Но раскрыть здесь свои сильные стороны - тоже не видно где.

Ну и как вариант - обойтись вообще без "ритуального" класса Ui 

[blood_shadow]

Ну и как вариант - обойтись вообще без "ритуального" класса Ui 

насчет этого не понял это как? прописывать форму вручную?

[Igors]

насчет этого не понял это как? прописывать форму вручную?

Лучше грузить из ресурса