Russian Qt Forum

Привет.
Есть данные, над которыми 2 модели для разного отображения.
У меня закрались сомнения, что данный дизайн правильный, поскольку обновление данных в одной модели, нужно как-то обновить вторую модель (сейчас делается просто reset). Чтобы вы посоветовали? Как принято делать в этом случае?
Спасибо.

а что мешает использовать одну модель? побольше бы подробностей :)

Так данные отображаются по-разному. rowCount() и data() по-разному реализованы и редактирование по-другому выглядит.

Отображение суть роль View, а никак не модели.
Если у вас данные одинаковые, но разное отображение - вам надо менять View а не Model.

А так да - мало данных, нет кода, советовать нет смысла.

2 экземпляра данных - принципиально неверно, хоть с MVC хоть как

Экземпляр данных один, указатель на данные в модели. Просто когда данные меняются из одной модели, другую нужно как-то уведомить, что данные изменились.

Тем не менее информацию о столбцах, строках и т.п. выдаёт модель, а не view.

Есть QByteArray. В одной модели он отображается и редактируется как hex, в другой, как bin. Сам массив данных хранится ессно не в модели, а в каждую из моделей передаётся указатель на один и тот же массив.

У вас проблема с архитектурой.
Модель должна отдавать QByteArray. В любом из случаев.
Делегат должен меняться. И именно в нём обрабатывать данные как вам нужно.
В результате получается 1 модель, 1 View, 2 делегата.

Поэтому и тред =)
Что значит модель должна отдавать? из data() возвращать?
Т.е. заголовки/размер столбцов, отображение данных - это не из модели возвращать? Я думал тут 2 View надо...

Смотри...
Model хранит данные.
View запрашивает данные.
Делегат отрисовывает что-то на основе данных.

Вот так работает система.

А как же rowCount() and columnCount()? Модель же их отдаёт. Для hex и bin они разные у меня. Что делать в этом случае?

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

Я нигде не говорил, что данные разные. К примеру, в случае hex у меня будет 16 столбцов, а в случае bin - только 8.

Модель ни чего не знает о количестве столбцов, будет ли это таблица, или график, или еще что-нибудь. У нее есть данные, а вьювер эти данные уже отображает. В твоем случае, например, у тебя есть массив из 32 чисел. Хекс должен этот массив интерпретировать как таблица из 16 столбоцов, а бин - как таблица из 8 столбцов. Модель на таблицу ни как не влияет. Может ты захочешь сделать еще один вьювер хекс-бин, который будет отображать в виде графика.

Ну так вот этот-то метод в модели http://qt-project.org/doc/qt-4.8/qabstractitemmodel.html#columnCount , а не во view.
Можно немного поподробнее, пжлста, как мне объединить эти 2 модели в одну.

Храни в моделях указатель на данные.

Спасибо, кэп. Я именно так и делаю, о чём написал уже выше по треду. Вопрос был в том, что если данные меняются в одной модели, как уведомить об этом другую модель? Если архитектура, как заметили выше, не совсем правильная, то как объединить эти две модели в одну, учитывая, что количество строк/столбцов разное?

Вариант такой. Для функции data указывать роль. Создай две пользовательских роли hex и bin. В зависимости от роли будут и данные.

Окей, с data разобрались. Чё делать с row/columnCount?

Делегат отрисовывает ВСЁ как хочет. И никто ему не указ. Вообще.

Если уж так хотите сделать всё в модели - тупо сделайте в ней 2 режима HEX и BIN.

А как все начиналось... "неправильная архитектура"... а закончилось все как всегда - сделайте тупо. :)

Вячеслав, все вы нормально делали, научите хранилище информировать модели о своем изменении (отсылкой сигнала), а в моделях ловите этот сигнал и обновляйте, только изменившиеся в хранилище данные.

Old я не понял вас. Какой сигнал, какие изменения в хранилище :)

А делать "тупо" нужно всегда, когда нужно сделать быстро.

Это потому, что вы ни секунды не думали над тем, о чем спрашивал ТС.

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

Аха..) Вот после таких заявления, я начинаю лучше понимать пословицы типа:
"Я не настолько богат, чтобы тратить деньги на дещёвые вещи")

Главная мудрость пословиц - они друг другу противоречат, если не знали :D Ибо нет золотой середины.

Но когда нужно сделать за день - нет времени расписывать архитектуру.

Я подумал. И вижу что у вас появилось хранилище. Откуда - я хз :D У ТСса 2 модели. Мб сначала предложить создать отдельное хранилище? А то вы как фокусник - создали хранилище из ниоткуда :)

Вы предлагаете вынести хранилище из модели. НО... Но модель это и есть хранилище. Вынести функционал - это тоже костыль :D

А так то, для внимательных - я предложил 2 варианта. Красиво и медленно или тупо и быстро.

2Верес. Перечитайте первое сообщение. У ТС есть хранилище (данные) и есть две модели.
Может вы и подумали, только вряд ли поняли. Зато постов важных написали не мало.

Почитайте сами. У него есть ДАННЫЕ. Над которыми 2(две) модели.
Нет у него хранилища. У него сырые данные. Было бы хранилище, вот тогда он бы поступил по вашему совету :)

QByteArray это простое хранилище данных, к нему легко можно добавить сигнал о модификации.

Что там друг-другу противоречит?
Я уж молчу о том, что ситуации, когда "пятки горят" и надо за один день сделать абы как - это подход реальных "find/replace/if-else/case" профессионалов) Это, конечно, к крайностям не относится)     

Давайте реализуйте мне за день программу сложности "я нихрена в этом не разбираюсь в первый раз вижу но делать надо". Я посмотрю на вашу архитектуру :)
Архитектура в первую очередь строится на знании предмета. А когда форс мажор, тут какие знания - тут лишь бы работало и быстрее.

PS футуристичные рассказы как люди писали программы с превосходной архитектурой за день можете не приводить - единственный в них смысл в том, что эти люди знали предмет и имели заготовки по нему :)

Так вот я вам и повторяю (десять раз и снова), если ставятся условия срочно-срочно наваять что-либо абы как за один день, (у студентов за еду) то у меня, лично, к таким шарашкам никакого доверия нет и никогда не было.. И не будет..( Поскольку, только лишь сама постановка такой задачи и сами требования,  уже подразумевают весь это "профессионализм" как закрасчиков, так и горе-разработчиков, которые подписываются под этим.. А в итоге имеем  то, о чём я и говорил, упоминая смысл той пословицы..   

1. Реализовать в модели слоты.
2. сделать центральное событие.
3. зацепить его на слоты моделей.
4. Вызывать центральное событие для обновления данных.

И не надо лохматить бабушку.

Вопрос был "как обновить" а не как построить архитектуру.

Вот vbv и поставил жирную точку :D

Однако лохматить бабушку можно и продолжить, если у моделей имеется пункт "удалить запись", который должен быть своим у каждой модели :D

В модели уже есть слот. Называется refresh. Да и сигнал об изменении данных тоже модель имеет.

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

Ну и нормально, тогда что Вас тревожит?

Ну и чего Вы взъелись на совершенно безобидное высказывание? Один день или сколько - сроки всегда есть. Также правильно что какое-то более или менее глубокое понимание приходит где-то с версии 1.0, а до этого "ну вроде так правильно, а там посмотрим" - это нормально.

to Max: такие "шарашки" называются форс мажор и работа в команде. Без них никуда. Особенно когда у человека случается что-то и он выпадает к чертям. А второго специалиста нет.

Архитектура строится на знании, повторюсь. Знание приходит с опытом. Опыт приходит медленно. Потому одна из формул на которой зиждется разработка каждой программы выглядит примерно так

Время разработки = время изучения предмета + время написания альфы + поиск и изучение библиотек + переработка архитектуры + написание релиза.

В случае срочности формула будет выглядеть так
Время разработки = поиск и изучение библиотек + написание релиза(оно же альфы). И никуда вы от этого не уйдёте. Только в идеальных условиях есть время на изучение, пробы, тесты, написание альфы, бета версий программы.

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

PPS можете не верить, но такой "срочный" подход плодит больше шедевров, чем размеренная деятельность.

У нас повсюду такие шедевры, начиная от дорог и автомобилей...

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

Когда только начинал карьеру младшим sw developer'ом, был у меня в команде парень с небольшим опытом работы, что-то около двух лет, который отлично умел писать много много говно кода в день. А вся команда за ним фиксила это кривой код. Но он считал себя супер профи, бегал в комнату к архитекторам каждый день, но продолжал делать говно код.
Производительность по количеству строк кода у него была раза в 2-3 выше чем у других в команде, а вот качество его кода было как минимум в те же 2-3 раза ниже.

Я сам был на такой должности :D Учащимся.
И самое главное достоинство того парня (говно кодера, по вашим словам) - что его проекты работали так как надо и за короткое время.

А у специалистов высокого уровня на это просто не было времени. Вот просто у него неделя на разработку архитектуры, неделя на альфу+тестирование, неделя на бету + тестирование. При это остальные его проекты стоят.
А у новичка 2 дня на один проект. Это так называемое затыкание дыр.

Если бы фирме нужен был качественный код, его бы обучили/выгнали. Но фирме нужны были готовые проекты и за короткое время. И пофиксить уже готовый проект гораздо проще, чем написать с нуля.

PS и зря вы его так называете. Если вы его не обучили стандартам, которые используются в вашей фирме - это ваша проблема :) Ну и вопрос на засыпку - был ли у вас в фирме официальные правила оформления программного кода?

Да ладно.  ;D

Ага. Гораздо проще.
Но в противовес -  добавлять новый функционал сложнее.

Так одноразовые проекты (сделал, отдал и забыл) никому не нужны. Нормальные проекты можно развивать... в отличие от...

Представьте себе, сотни работников НИИ с вами не согласятся :D

Не знаю, мб в других областях программирования "одноразовые" и не нужны, но вот провести НИР без одноразовых не получится :)
И таки да - иногда на один НИР приходится по 2-4 "одноразовых проекта".

PS Научно-Исследовательская Работа.

Есть хорошая книга по этой теме.

Эдвард Йордон.
Путь камикадзе. Как разработчику программного обеспечения выжить в безнадежном проекте.

И да Верес, видимо, ярый представитель быдлокодеров, уж извините) иначе бы не оправдывался.

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

PS не извиняю. Хамло вы редкостное. Ну оскорбляя других, вы выставляете себя хамом, так что увы.

PPS надо понимать точку зрения себя и собеседника. Вы же меня не понимаете. Вы отрицаете необходимость срочного написания программ, но куда вы от неё денетесь?

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

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

Еще пример из личного опыта:
Может вам знакома такая библиотека как WebRTC. Это открытый говнокод от гугла. Жутко кривое. 2 года фиксили эту библиотеку для продукта, чтобы оно хоть как-то работало. Там весь набор, начиная от дедлоков, рейс кондишенов, огромного количества крешей и заканчивая ликами убивающими айфоны и айпады до состояния когда спасает только хард ресет.

По затратам человеко-часов можно было с нуля все это написать куда более прямо. Либо можно было взять более менее прямую библиотеку и на её основе делать.
Так что говно код сейчас, это всегда гемор в будущем.


Я не спорю, бывают ситуации когда нужно сделать маленькую прикладную апликуху, которая вообще может потребоваться только на этапе разработки/тестирования, тут можно не задумываться над архитектурой и немного поговнокодить.

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

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

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

А вот программа написанная за месяц уже может претендовать на звание не говнокода. Но это месяц без программы :)

PS к тому же такая программа вырисовывает будущую архитектуру. Можно сказать поднимает навык :D

Все всегда предусмотреть сложно, но не невозможно!

Просто нужно прежде чем что-то делать, подумать как это сделать. Часто спихивая очередную задачу на разработчика, все целиком ложиться на его совесть и даже код ревью ничем уже не поможет, т.к. если все просто, то никаких вопросов нет, а если все сложно, то врядли кто-то будет вникать в архитектуру. Глянули, закомплитили -> профит.



Логика неверная. Это просто желание схалтурить сейчас и отодвинуть все на далекое будущее. Хорошо если утилитка нужна только на этапе разработки/отладки. А если это часть конечного продукта, то халтурить не стоит.

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

Расписывать бесполезно, как я понял.

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

Хорошую программу переписывают полностью как минимум один раз.

ИМХО.

Будем честны - идеал недостижим, сколько не переписывай  ;D

ну если все делать на отъе**сь, конечно так все и будет))

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

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

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

Очередной идеалист. Все мы через это проходим :D

Гейтс Билл был таким же, но все мы знаем, что получилось  ;D

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

П.с. я не идеалист, просто у меня есть личная отвественность. чего и вам желаю.

Личная ответственность != затягивание срочной работы :)

Как и везде тут нужно идти по тонкой грани между говнокодом и идеальным кодом.

PS если хоть 1 программист в мире скажет - "я не говнокодил никогда", то его можно сразу бить камнями - врёт как дышит.

Нифига себе "тонкая грань". :) Вы указали две крайности между которыми все. :)

ИМХО крупный проект сложно написать круто с первого раза. Поэтому и выпускают версии 1.1, 2.0 и так далее.

Дело не в сроках. Наивно полагать что "вот я все тщательно обдумаю, сделаю основательно - и все будет Ok". Обдумывание хорошо (и даже необходимо) - но до определенного предела. Если обсуждать будущий проект с коллегами (исполнителем, заказчиком), то в какой-то момент становится заметно: разговор пошел по кругу, ничего принципиально нового уже не вносится. И тогда надо начинать делать. И вылезут проблемы  которые  недооценили (а иногда и не подозревали). Это нормально

И тогда надо начинать думать и проектировать. Желательно вдалеке от компьютера с блокнотом и карандашом.

Да, если из разработки выкинуть главный этап - проектирование, то проблемы вылезут практически сразу. Это нормально.

Все программы рождены из гавнокода :)
Это как яйцо и курица, правда порядок мы точно знаем.

Говнокод -> идеальный код.

плюсую.
именно с блокнотом и карандашом, а не "в уме", как некоторые очень уверенные в себе говнокодеры :)

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

Ну это всего лишь самореклама типа "тихо! Чапай думать будет" :) Чтобы возникли мысли - нужен какой-то материал, опыт, а откуда это возьмется на начальном этапе? Поэтому подозреваю что в блокноте ничего путного так и не появится :) Приведите живой пример такого "проектирования", а если затрудняетесь - я дам проект.

Вы поговорили с заказчиком, это начальные данные. После этого задача разработчика продумать, как это можно реализовать: какие будут классы, какие объекты, как они будут взаимодействовать - это и есть проектирование.
И только когда это будет осознанно и описано, можно приступать к "надо начинать делать".

Весь софт каким вы пользуетесь так разрабатывается.

Old вы это применимо только тогда, когда вы разрабатываете программу в своей специализации. Т.е. у вас уже было множество таких проектов и именно ВАШ опыт и ВАШИ ошибки и ВАШ говнокод даёт вам возможность сидеть с блокнотиком :)

А когда у вас нет ни ОПЫТА, ни ОШИБОК, ни знания предмета, то вам придётся сесть и писать говнокод. И смотреть что получается. И получать опыт. И только ПОТОМ ПРАВИЛЬНО проектировать с блокнотом :)

А что можно написать ничего не зная о том что пишешь? :)
Вначале нужно сесть с блокнотом, книгами и разобраться, а только потом садится и писать "class MainWindow".

Мда )

Самый удачный пример - надо заколотить гвоздь. Есть молотки, стенка и гвозди. Можно сесть с блокнотом и нихера ничего не делать, ведь ты не знаешь что такое молоток, гвоздь, только названия. А можно пощупать молоток, понять где твёрдая часть. Пощупать гвоздь. Пощупать стену. Попробовать забить. Попробовать забить по другому. По третьему. И так до достижения результата. Потом накопится опыт и ты будешь забивать двадцатку одним ударом.

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

Потом, если говорить о реальности, придётся нанимать нового удальца-молодца, поскольку первый перебьёт себе все пальцы) А вместе с ним ещё и новую стену и гвозди)

Речь идет о том как надо делать, а не о том как надо учиться делать.

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

Это если он сообразит, что гвоздь нужно забивать в стену молотком. В реале он может молоток куда нибудь себе вставить или проглотить гвоздь или ... /* фантазия у некоторых очень богата :)  */

Мы берём нормальную и психически здоровую особь.

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

Вспомнился старый мультфильм где там хвастуны землянику собирали  :)

Та вы не комплексуйте. :)