 |
|
|
 
|
|
[Qt4] Наследование QVector 
| BiTOk |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 43 Регистрация: 23.12.2010 Репутация: нет Всего: нет |
Добрый день. Возникла потребность в наследовании QVector. При этом шаблонный аргумент должен быть задан статически. Написал код вида:
class Domain{...}; class DomainList: public QVector<Domain>{Q_OBJECT ....} Но при компиляции получаю кучу ошибок в соответствующем moc файле. Что именно я делаю не верно? |
|||
|
||||
Загрузка ...
| alexSl |
|
|||
 проходил мимо Профиль Группа: Участник Сообщений: 28 Регистрация: 22.2.2008 Репутация: нет Всего: нет |
Q_OBJECT - лишнее.
|
|||
|
||||
| kemiisto |
|
|||
 Дикий Кот. =^.^=  Награды: 1 Профиль Группа: Участник Клуба Сообщений: 3292 Регистрация: 29.7.2007 Репутация: 8 Всего: 160 |
 Этот макрос надо указывать только для классов (прямых или косвенных) наследников QObject. QVector не такой!  И тут, конечно, наследование - лишнее. Точнее, оно тут абсолютно не уместно. Композиция же наше всё! -------------------- |
|||
|
||||
| BiTOk |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 43 Регистрация: 23.12.2010 Репутация: нет Всего: нет |
alexSl,
спасибо, помогло kemiisto, наследование тут в тему, я просто задачу описал не до конца. Конкретно для этого класса мне надо реализовать несколько видов поиска по разным ключам, хранящимся в объектах, хранящихся в векторе. |
|||
|
||||
| kemiisto |
|
|||
|
Дикий Кот. =^.^= Награды: 1 Профиль Группа: Участник Клуба Сообщений: 3292 Регистрация: 29.7.2007 Репутация: 8 Всего: 160 |
Это вряд ли что-то меняет. Ни QVector, ни std::vector не проектировались под возможное наследование. Во-первых, отсутствие виртуальных функций как бы намекает. Вы не сможете переопределить ни одну функцию. А отсутствие виртуального деструктора может аукнуться утечками памяти. Во-вторых, вы не получите никаких преимуществ от наследования, т.к. нет protected-членов. В-третьих, если использовать композицию, в будущем можно с лёгкостью заменить QVector на другой контейнер. -------------------- |
|||
|
||||
| BiTOk |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 43 Регистрация: 23.12.2010 Репутация: нет Всего: нет |
А как тогда тут реализовать, чтобы не пришлось ручками прокидывать паблик методы вектора, ибо их дошыша надо использовать в коде, использующем унаследованный от вектора класс.
|
|||
|
||||
| kemiisto |
|
|||
|
Дикий Кот. =^.^= Награды: 1 Профиль Группа: Участник Клуба Сообщений: 3292 Регистрация: 29.7.2007 Репутация: 8 Всего: 160 |
BiTOk, мне видится 2 варианта:
-------------------- |
|||
|
||||
| BiTOk |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 43 Регистрация: 23.12.2010 Репутация: нет Всего: нет |
Второй вариант нарушает принцип инкапсуляции и главную цель программирования - сделать код проще, более централизованным в данном случае.
В общем и целом не вижу ничего страшного в использовании в данном случае наследования, оно позволяет не нарушая никаких принципов ООП и вообще подходов к проектированию (Макконнелл) реализовать то, что мне надо. |
|||
|
||||
| kemiisto |
|
||||
|
Дикий Кот. =^.^= Награды: 1 Профиль Группа: Участник Клуба Сообщений: 3292 Регистрация: 29.7.2007 Репутация: 8 Всего: 160 |
Чушь. Инкапсуляция в ООП - всего лишь один из механизмов сокрытия информации (information hiding). Тысячи их. Этих механизмов. Информацию (например, детали реализации) можно прятать не только на уровне классов. ВНЕЗАПНО (для тебя это, возможно, будет откровение) есть языки в которых нет классов. Но и на уровне модулей, например. В С++ нет модулей, но есть костыли в виде заголовочных файлов, которые кое-какие детали реализации (пусть и не все) скрывать таки позволяют. И позволяют делать это до той же степени, что и на уровне классов.
А нынче что, за нарушение принципов ООП уже "светит" что-то? Проектирование (как и программирование) бывает разное. Объектно-ориентированное, структурное, функциональное. Не ООП единим. И ты таки нарушаешь очень важный принцип ООП - используешь класс не по назначению. Я указал на особенности класса QVector, которые позволяют считать идею наследоваться от него как минимум не самой удачной. Макконнелла выкинь. -------------------- |
||||
|
|||||
| Shaggie |
|
||||
 Опытный Профиль Группа: Завсегдатай Сообщений: 570 Регистрация: 21.12.2006 Где: outer space Репутация: нет Всего: 72 |
Сделай класс сервиса, который будет в АПИ принимать коллекцию и способ поиска. Интродюсить поиск в коллекцию нехорошо и как раз против принципов ООП. Желательно чтобы каждый класс выполнял одну свою задачу, а у тебя список получается и хранить умеет, и искать по-всякому. Завтра тебе потребуются вектор доменов и очередь доменов, два отдельных класса - будешь дублировать поиск в каждом классе? Или вынесешь в отдельного родителя и огребёшь проблем с множественным наследованием? Лучше вынести наружу и получить нормальный интерфейс под каждую отдельную задачу. --------------------
|
||||
|
|||||
| BiTOk |
|
||||||||
|
Новичок Профиль Группа: Участник Сообщений: 43 Регистрация: 23.12.2010 Репутация: нет Всего: нет |
Светит геморрой в будущем (а в данном случае проектирование идёт именно с использованием ООП).
Согласен, не по назначению. Но куда мне тогда приткнуть поиск? Отдельный класс для поиска городить - не очень разумно, ибо поиск всегда будет по вектору и поле зависит от содержимого класса Domain. Лепить поиск в класс, который использует DomainList тоже не очень разумно.
Не люблю революции, может ещё Кнута смахнуть со стола. Можно долго спорить хороши ли они, но пока я в основном соглашаюсь с мыслями, изложенными в этих книгах.
Ну а что нормального в таком интерфейсе. Отдельный класс будет заниматься поиском по структуре данных, при этом для каждой структуры придётся городить свой класс поиска? |
||||||||
|
|||||||||
| mes |
|
||||||||
|
любитель Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 7 Всего: 250 |
Как раз при таком "строгом" подходе как Ваш и светит проблематика в будущем..
во первых как раз наследование в Вашем случае нарушает главную цель программированния, добавляя лишнии связывания.. во вторых Вы не правильно понимаете инкапсуляцию... она предназначена не скрыть все можно, а помочь выделить единную сущность.. в третьих не Вы должны под язык / концепцию прогибаться, а он/она под Вас.. Добавлено через 1 минуту
слово "предикат" Вам ни о чем не говорит ? Добавлено через 2 минуты и 43 секунды
только не путайте значения слов : "соглашаться" и "поклоняться"  |
||||||||
|
|||||||||
| BiTOk |
|
||||
|
Новичок Профиль Группа: Участник Сообщений: 43 Регистрация: 23.12.2010 Репутация: нет Всего: нет |
Встречал его в матлогике, но сходу не переносится на эту ситуацию.
Не путаю, да и не со всем согласен в Макконнелле, но в основном там толковые мысли. Как Вы предложите реализовать вышеназванную задачу соблюдая все каноны ООП. |
||||
|
|||||
| mes |
|
|||
|
любитель Профиль Группа: Участник Клуба Сообщений: 7954 Регистрация: 14.1.2006 Репутация: 7 Всего: 250 |
с канонами это не ко мне.. но пример показать могу.. правда Вы не указали ограничения на компилятор и библиотеки, поэтому предположу что C++0x принимается : http://liveworkspace.org/code/e1ea4d7a52ba...3d2c1cfaa0a81fc Добавлено через 1 минуту и 41 секунду без С++0х подобный подход тоже возможен, но писанины больше.. |
|||
|
||||
| BiTOk |
|
|||
|
Новичок Профиль Группа: Участник Сообщений: 43 Регистрация: 23.12.2010 Репутация: нет Всего: нет |
Лямбда функции.. И на кой они мне в моём случае? Мне надо, чтобы этот поиск был доступен из разных мест в программе там же, где доступен DomainList.
|
|||
|
||||
|
|
| Правила форума "С/С++: Кроссплатформенное программирование, QT/Gtk+/wxWidgets" | |
|
|
Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, JackYF, Любитель. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | С/С++: Кроссплатформенное программирование, Qt/Gtk+/wxWidgets | Следующая тема » |
[ Время генерации скрипта: 0.0589 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |