Это считается хорошим стилем? Почему Qt генерирует код с композицией этого класса а не наследованием?

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

На самом деле не правильно выбирать простые примеры. Они никогда не решают реальных задач. 

Для калькулятора достаточно одного main.cpp файла в который запихать всё целиком. Тут даже .ui файл не нужен. Где слоты, там и логика.
Я бы даже не стал писать отдельный класс для логических операций. Это скорее усложнит читабельность, чем реально поможет.

Все-таки для меня бизнес логика это не вообще любой маломальский код, который приходится писать в слотах, а реализация модульных вещей: парсеры xml, работа с БД, делегаты, унаследованные виджеты, работа с сетью и т.п.


На самом деле я видел 3 варианты использование класса сгенеренного от .ui файла:
- полное наследование, при котором область видимости UI пропадает
- аггрегация UI класса
- использование указателя на UI

Где-то даже тема была о выборе одного из этих методов. Были и плюсы и минусы подходов. Но как я не пытался найти объяснение троллей, так и не нашел.

Это сообщение отредактировал(а) SABROG - 4.8.2009, 14:36

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

Хороши вопрос. Многими был задан ранее.

Серьезный проект на Qt - http://www.qutecom.org/

Да, вариант с наследованием мне тоже определенно нравится больше, но в таком случае хотелось бы заставить Qt генерировать объекты в хотя бы в protected секции (я уже не говорю про функции доступа)  

А чем QtCreator не серьезный проект? Исходники есть. Еще можно посмотреть в сторону QDevelop и qutim. В принципе сами утилиты Qt: Designer и Assistant достаточно серьезны. Можно конечно еще серьезней - KDE.

azesmcar, Нет у uic-а такой опции.
Делай по другому.
Подключай генерированные хидеры, но не используй объект из namespace::Ui, наследуйся от объекта Ui_[имя формы]. Оно же тебе известно.

Это сообщение отредактировал(а) andrew_121 - 4.8.2009, 14:50

а что это изменит?

Пихай предков в протектед.

зачем в protected, сразу в private. Это ясно, я имел ввиду в самом классе забить все в protected. Ладно, нельзя так нельзя.

Я привык формы создавать дизайнером. Но все остальное ручками пишу. Может средства разработки как-то иначе этот процесс выполняют...

Добавлено @ 14:58

Ну если уж невмоготу, измени uic, его коды прилагаются  

Это сообщение отредактировал(а) andrew_121 - 4.8.2009, 14:59

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

Может быть тебе будет интересна эта ссылка.

Такой вопрос.

Есть ли гарантия, что Qt завтра не станет генерировать класс Ui_mainwindowClass наследником QObject? В этом случае появится проблема.

наследование от двух классов, наследников от QObject - не разрешено.
Может потому в генерированном исходнике используется вариант с агрегацией?

Это сообщение отредактировал(а) azesmcar - 4.8.2009, 15:00

Нет.
С версии 4.6 многое измениться. Точнее SABROG знает. Потом, еще что-то радикально могут изменить.

Это сообщение отредактировал(а) andrew_121 - 4.8.2009, 15:05

Я думаю, uic специально генерит всё в public, чтобы ты сам потом решал, как это использовать. Если хочешь все члены спрятать (а так обычно и надо делать), используй private-наследование.

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