Из чего состоит ядро для программы? Верно ли я определил?

Кто-нибудь хоть этот паттерн ядром называет?

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

Но если ты делаешь на культях, то там уже устоявшийся паттерн описания UI есть. Пробовал хоть что-нибудь слепить в qtcreator? Ты попробуй пустышку сделать и глянь код результата.

Очень странный вопрос для прикладной математики. Попробуй почитать что-нибудь про проектирование программного обеспечения.

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

На счёт проектирования прикинул. В ядре будут те сервисы которые перечислил в посту выше + функции нужных мне мат.вычислений.

Модель данных в отдельной библиотеке, View - Qt файлы, Presenter - отдельная библиотека.

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

Надеюсь понятно описал, если нет, то могу ещё написать.

Извините за глупые вопросы.

Дак я ж написал, что нам паттерны проектирования не давали.

И ты хочешь, чтобы тебе теорию на форуме дали что ли?

Никаких паттернов проектирования не было у нас не было.

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

Завистюит от программы. Скажем в числодробилках ядром называют то что непосредственно ведёт расчёты, а все остальное обвязка (GUI если есть, работа с путями-файлами, выбор режимов работы, сброс данных и тд)

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

На бумажке алгоритм составлю, а вот запрограммировать, ну говонокод 100% сделаю, а вот чтобы красиво с паттернами и архитектурой - это уже задачка 🙂

Понял!!! Кажется дошло, что там должно быть!!! Спасибо!!!

Дак я и не прошу теорию. Просто спросил правильно ли прикинул структуру ядра или нет. Написал, что не давали, чтобы не писали, что я балду гонял 🙂

Тут уже был пост и кажется до меня дошло, что там должно быть 🙂

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

У нас не было тонкостей программирования, а только основы.

Что бы вы посоветовали в данной ситуации?

Изучать исходники готовых проектов. Тысячи их!

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

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

А институт какой? Ну так, для себя спрашиваю…

Про проектирование ПО есть во-первых стандарты (начиная с ЕСПД), во-вторых куча литературы, которая написана проще и понятнее. Там у тебя будет и архитектура, и разделение на компоненты, и т.д. Подходы есть разные, у них свои преимущества и недостатки, но хотя-бы 3-4 надо знать к моменту выпуска…

Настоятельно советую до написания кода расписать схемы взаимодействия компонентов «на бумаге» (заодно в текстовую часть и презентации засунешь) - сильно сократит время реализации.

Начал пилить реализацию и понял, что пишу говнокод который поддерживать и расширять не смогу

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

нас первые занятия 2-3 не допускали - на бумажке писали алгоритмы

Я думал такое вымерло как класс уже давно.

твоя программа это одна форма может с несколькими вкладками так как данных монго по размеры толщину стен, паркет,… и кнопками сгенерить чертеж 3D модель или что там еще придумаешь.

как формы делать читай доку по Qt.

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

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

ты уже реши ты программу про дом с расчетами и какой-то визуализацией пишешь или свой Qt или Gtk. Если ты думаешь что сможешь написать свой аналог qt и потом как пример на этом движке свою прогу про дом то дерзай, но шансов не много :)

Прочитай книгу «Чистая архитектура» Роберта Мартина. Она есть в переводе, есть на авито, есть в магазинах, есть где скачать бесплатно… Книга простая, можно читать как художественный текст, с картинками и примерами архитектур.

А в целом, несколько советов:

1. не строй космолет

2. не реализовывай то, что можно реализовать позднее

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

4. не старайся делать супер гибкую программу, это приведет к сложностям в ее переписывании, поэтому оценивай сколько нужно сил на то чтобы повысить универсальность и сравнивай с силами которые нужны на минимальный функционал + переписать потом с доп функционалом, обычно универсальность оказывается «в пролете».

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

Если уж читать, то «банду четырех» про ООП. Архитектура из ООП сама вытекает.

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

Посмотри в сторону FLTK или Сишного nuklear.

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

Хорошие книги про то, как писать код, начинают хорошо восприниматься когда уже есть опыт. Эта, как начальная, – очень неплоха.

Банда четырех это не про архитектуру, это про обычные вещи из теории систем в переносе на ООП.

Пусть ядро вычисляет что вычисляется. Получает задачу, выдает ответ в каком-то удобном тебе формате, можно даже асинхронно. Потом с этим готовым оттестированным ядром работаешь хочешь из консольной обвязки, хочешь из gui с окошками, а я бы так вообще взял встраиваемый веб-сервер и работал бы из браузера. Отдельно пишешь конвертер из формата который понимает ядро в формат экспорта и например в json который можно загрузить в браузер и отрисовать 3d-библиотекой javascript. Ядро работает только с промежуточным форматом, ни про какие окошки, САПР и прочее оно не знает. Типа функция посчитать_краску_на_стене - принимает координаты многоугольника пола, высоту стен, массив размеров проемов в стене, количество слоев, для каждого слоя расход краски, % запаса и выдает число. Оттестируешь эту математику, поймешь какие данные нужны, потом будешь думать как это ввести и отрисовать. Для тестирования можно по быстрому накидать консольный интерфейс с пайпами.

Окошки в ядро тащить не надо если конечно не пишешь менеджер этих самых окошек.

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

Делать иерархию классов для материалов, типа «жидкость» и наследники в виде краски с расходом в литрах или «напольное покрытие» с полем «высота» я бы тоже не стал. Надо будет - сделаешь потом рефакторинг когда почувствуешь что часто пишешь одно и то же.

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

Ты сейчас supervisor или systemd изобретаешь?

А зачем тебе Qt?

А вот и иксперды подъехали.

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

Всем спасибо!!! Въехал и пошло поехало дело. Уже накидал в Qt окошко для рисования и добавил туда фон миллиметровки. Также реализовал рисование в нём. Можно рисовать примитивами пока только квадратами, прямоугольниками, кругами и линиями. Сейчас реализую рисование ломанной линией.

Всем спасибо!!!

(GUI если есть, работа с путями-файлами, выбор режимов работы, сброс данных и тд)

Это вообще удобно на питоне.

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

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

1. Модель это данные и методы работы с ними. Должно быть, в основном, зависимо само от себя.

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

3. Контроллер это тонкий слой совместимости между представлением и моделью. Проверяет данные, форматирует данные, вызывет методы модели.

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

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

1. Оказывается, что прямо на сущностях (ещё смотря что у тебя такое «сущность») выполнять какие-то операции становится сложно. Становится непонятно, куда лучше запихивать логику - ты переносишь бизнес-логику в сервисы.
2. Оказывается, что у тебя есть множество разных источников данных. С этим становится сложно работать. Хочется унифицировать - в этот момент, возможно, появляются репозитории.
3. Оказыватся, что у тебя вдруг сервисы стали жирными и непонятными. Какие-то сервисы стали «как бы бизнесовыми», а другие «как бы техническими». А что-то вообще оказалось в приватных методах. А что-то и не совсем понятно, куда запиховать. В этот момент у тебя появляются всякие классы на один метод, а-ля сценарии-использования. И, возможно, ещё и какой-нибудь медиатор.
4. Оказывается, что ты захотел протестировать, всякого намокать, вообще сделать вещи взаимозаменяемыми - и в этот момент ты начинаешь как человек пилить интерфейсы.

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

Ну и на начальном этапе я б советовал не в теоретическую литературу закапываться, а пока почитать всяких статей, блог-постов, сравнений и обсуждений на сайтах - по мере необходимости. Всё равно пока с бедой не столкнёшься, скорее всего, не поймёшь, зачем тебе именно сейчас именно этот шаблон проектирования. А там и объясняют порой попроще. Уже когда появится базовый опыт, понимание и общее знакомство с большинством основных шаблонов - тогда возьми хорошую книгу и приведи голову в порядок.

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

Ну и сорцы читай, их полно. Погугли чёто там, «Qt Apps Open Source», «Qt Awesome», «Qt Full example» и так далее. Обязательно хорошее чего найдёшь, натаскаешь оттуда. Удачи.

Пиши как пишется. Паттерны для бездельников.

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

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

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

Предлагаю посмотреть: https://github.com/CadQuery/CQ-editor

Он маленький и немного похож на то что вы планируете написать.

Как выше написали – зависит от программы. А заодно и от фреймворка. К примеру, то, что в Qt понимают под Model-View, имеет некоторые отличия от классического MVP. Другими словами, ГОСТа или какого-нибудь ISO xxxxx, который предписывает тебе, что такое ядро в программе, нет.

В качестве примера одного из вариантов организации можешь глянуть мой проект. Я сначала не задавался целью сделать отдельное ядро. Но при этом старался не жарить мух вместе с котлетами и проектировал код по возможности аккуратно. В итоге у меня практически сами собой образовались некоторые «ядрёные» вещи, которые в репе по ссылке я сложил в каталог core. Туда вошли общие структуры данных, константы, некоторые алгоритмы и набор классов экспорта-импорта в разные форматы файлов (core/formats). И никакого GUI, разумеется.

На втором уровне – то, что лежит в model. (Это как раз в кутешном понимании Model-View.) Плюс туда же пошло кое-что, что зависит от GUI, но не зависит от виджетов (не скажу, что это правильное решение, но учитывая, что начинал я с Qt4, на её структуру это легло хорошо).

Наконец, на верхнем уровне GUI на QtWidgets, каталог app. Я планировал рядом с ним положить ещё каталог app-qml и сварганить в нём альтернативный GUI на QML с теми же core и model. Но к сожалению, до QML мои потные ручонки ещё не дотянулись. Зато есть пример консольной программы contconv, основанной на том же core.

Это не образец «как надо делать», просто один из примеров, как можно сделать, чтобы держать исходники в порядке. Не единственный и скорее всего не самый лучший — но в моём случае он себя оправдал.

Ну говнокода много, но иной опенсорс изучать - психику калечить. Я вон тоже будучи студентом опенсорс высрал на гитхаб, он даже работает и какие-то звёзды имеет. Но считать что там не фантастический говнокод и архитектура уровня тяп-ляп вроде работает и ладно, такое себе. Сразу уж тогда хорошие проекты накидывай если предлагаешь такое.

Есть книга head first «Паттерны проектирования», она правда на java, но с учётом знания операторов и правила пяти вполне и на С++ проканает, как учебное пособие по паттернам проектирования.

Не смей слишком усложнять или слишком упрощать

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