Объектно-ориентированное проектирование и дизайн приложений: взаимодействие, модели, системы, архитектура

В общем, дело такое. В ООП ничего не понимаю. Нужны некоторые уточнения парадигмы. Предполагается чистый C++ (без boost, stl и подобного).

Для примера: создание класса "журнал оценок". Двойки в который в детстве ставили многим.
1. Должен ли класс внутри себя хранить массив ФИО, Даты? Или не должен.
2. Не очень понятно как связать оценки, если должен.

Я так понимаю, что класс все-таки должен хранить внутри себя массивы. Но это использовать неудобно, местами вообще непонятно (вопрос пересечений ФИО и Даты для получения оценки). Как это может стать удобным мой мозг догадываться наотрез отказался, уперся в то, что массивы надо создавать вне класса и обрабатывать их вне класса, а класс должен содержать только единичные значения. Это, с единичными значениями и внешними массивами, может и удобно, но так не получается такой объект, который как бы заимствован из нашего мира и спроецирован в мир приложения, а, значит, такое ООП - не ООП.

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

0

Сообщение от daslex Вы дочитали вообще? У нас есть отличие. Там где у меня отчутствие записи в принципе, там у Вас присутствие записи с обозначением.

Не вижу такого, где у меня нужно лишнее хранить?
Если желаете хранить "справки" - пожалуйста.

Сообщение от daslex Минус где 'Н'. Если вдруг обязали 'Н' обозначать как 'О'(отсутствие). Надо проконопатить весь журнал. больше минусов я сказать не могу.

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

0

Ну, Вы просто не понимаете о чем я.
У Физрука журнал. В нем есть Петя, Вася, Катя
У Географа журнал того же класса того же года. Но у него в журнале есть только Петя, Катя, Дима.

У физрука нет записи о Диме вообще.
У географа нет записи о Васе

==========
В Вашем случае записи есть.

0

Сообщение от daslex Ну, Вы просто не понимаете о чем я. У Физрука журнал. В нем есть Петя, Вася, Катя У Географа журнал того же класса того же года. Но у него в журнале есть только Петя, Катя, Дима. У физрука нет записи о Диме вообще. У географа нет записи о Васе

Ах, совсем забываю об этом современном платном необязательном образовании.

Собственно в моём варианте - запись означает что оценка проставлена, если записи нет - значит оценка не проставлена.

И добавьте сами тип записи для такого поведения. У вас получится, я не сомневаюсь.

0

Так-то замечательная подсказка. Не надо думать, что я что-то плохое в ней увидел.

Добавлено через 3 минуты
Почему сразу платном.
Дима астматик с рождения. Его не вписывают в журнал по физре.
Вася географию по программе не проходит (набожная семья, верит в плоскость планеты).

0

Сообщение от daslex Так-то замечательная подсказка. Не надо думать, что я что-то плохое в ней увидел.

Всё окей, я просто устал уже

Просто выберите вариант данных который вас устроит. Меня бы устроили справки которые я привёл.

0

Сообщение от daslex Вася географию по программе не проходит (набожная семья, верит в плоскость планеты).

Это же не важно. Главное же что с Катей всё в порядке. Вера в плоскостопие - отдельная тема.
Создайте словарь: id , { Имя, Отчество, Фамилия, контейнер использования}. Контейнер хранит ссылки на места, где используют данный id. Журнал там зарегистрируется. В числе многих. Журналов в том числе.
Иначе один толстый журнал получается. Толстый - ключ.
А ведь всё начиналось так хорошо:

Сообщение от TC Пишу экспертную систему. В искусственном интеллекте не рублю. Обдумывал, обдумывал и выдумал. На свою голову. По всем признакам продукт получается умнее меня. Как реализовать? Стал много читать и есть. Ума прибавилось, но снова незадача. Пока бежал к клавиатуре реализовывать, придумал ещё умнее. Нет в жизни счастья.

1

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

Модель есть.
Структура хранения есть. (Пока что просто файл).

Я еще потом сюда все равно заходить буду.
Но сейчас есть с чем работать. И это замечательно.

Сообщение от IGPIGP Сообщение от TC

Я такого не писал

0

Сообщение от daslex Я такого не писал

Это вариация на тему. Плод коллективного разума. Воплощённого в ООПще.

0

Nosey, Файл мне мало подходит. Я же моделирую поведение. Дело не просто в журнале, а во взаимодействии.

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

Добавлено через 8 часов 29 минут
Меняю мнение. Вполне подходит. Провоцирует планировку новой системы. Это своеобразная сложность. Мне так-то понятно.
.....................
Тему можно переименовать в: "Дизайн проектирования. Взаимодействия. Модели, системы, архитектура программ."

Насчет советов не страдать, а кодить.
Хоть убейте, но система взаимодействия Журнала и обьектов не какой-то глобальный проект, хотя по некоторым советам я мог бы об этом начать думать. Сколько можно говорить, что это сложно. Учебный вариант не представляет особой сложности если человек умеет мыслить.

Разве это не нормально разделить какую-то систему на такие ее составные части.
1. Общий план вообще всего проекта (то, о чем мне писали, чтобы я вообще не думал, а сосредоточился на более мелких частях). Общий план - это модель в виде схем или диаграмм, uml это или салфетки роли вообще не играет.
Если система действительно громоздкая и достаточна глобальна, то тут вопросов быть не может. Кусочек взял, кусочек сделал.
2. Выцепить из общего плана наиболее важные моменты. В моем случае таким моментом стала подсистема, определяющая внедренцев. Также распланировал общий план и многие вопросы сами собой отпали.
3. Кодинг.
4. Я пока еще не дошел.

Таковы мои промежуточные выводы. Пока что я на стадии кодинга.

Добавлено через 3 минуты
Меняю мнение. Вполне подходит. Провоцирует планировку новой системы. Это своеобразная сложность. Мне так-то понятно.
.....................
Тему можно переименовать в: "Дизайн проектирования. Взаимодействия. Модели, системы, архитектура программ."

Насчет советов не страдать, а кодить.
Хоть убейте, но система взаимодействия Журнала и обьектов не какой-то глобальный проект, хотя по некоторым советам я мог бы об этом начать думать. Сколько можно говорить, что это сложно. Учебный вариант не представляет особой сложности если человек умеет мыслить.

Разве это не нормально разделить какую-то систему на такие ее составные части.
1. Общий план вообще всего проекта (то, о чем мне писали, чтобы я вообще не думал, а сосредоточился на более мелких частях). Общий план - это модель в виде схем или диаграмм, uml это или салфетки роли вообще не играет.
Если система действительно громоздкая и достаточна глобальна, то тут вопросов быть не может. Кусочек взял, кусочек сделал.
2. Выцепить из общего плана наиболее важные моменты. В моем случае таким моментом стала подсистема, определяющая внедренцев. Также распланировал общий план и многие вопросы сами собой отпали.
3. Кодинг.
4. Я пока еще не дошел.

Таковы мои промежуточные выводы. Пока что я на стадии кодинга.

1

Сообщение от daslex 1. Общий план вообще всего проекта (то, о чем мне писали, чтобы я вообще не думал, а сосредоточился на более мелких частях). Общий план - это модель в виде схем или диаграмм, uml это или салфетки роли вообще не играет.

Умные мысли:

Сообщение от преподобный Программуальд Кодус Копипастис: Нужно любить uml в себе, а не себя в uml.

Сообщение от Наставления по боевому программированию: У штурмового кодера есть только два союзника: инт, дабл... и флоат!

1

Сообщение от daslex Тему можно переименовать в: "Дизайн проектирования. Взаимодействия. Модели, системы, архитектура программ."

daslex, может лучше так: Объектно-ориентированное проектирование и дизайн (обсуждение) ?

1

0

0

0

0

Я тут немного накодил. Не в С++, правда, но это не важно.

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

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

Гораздо проще описать запрос выборки, чем регулярное выражение парсинга текста на сущности. Поскольку запрос читабельнее, то и корректировать его должно быть легче, наверное. Я имел небольшой опыт с запросами. Регулярки же удобны, но все-таки трудно читаются (с ними опыта не имел).
Без БД придется писать интерфейс добавления, редактирования, удаления. Рост веса структуры в файле провоцирует сложность поддержки такого интерфейса.

БД удобнее файлов постольку, поскольку при переходах на другие языки, в конечном итоге намного меньше проблем. А я ориентируюсь не только на C++. Во многих языках можно работать с БД одинаково, ибо БД она и есть БД, но гораздо реже можно одинаково работать с файловой системой и файлами. Это я по своему скромному опыту имел возможность пронаблюдать.


Так что сейчас если кто-то хочет дать рекомандации, то я бы посмотрел на рекомендации работы с БД в С++

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

0

Сообщение от daslex Хотя описание таблицы в файл - по мне весьма интересный способ увидеть важные взаимосвязи разных таблиц. (учиться их видеть).

У СУБД есть инструменты для просмотра схем данных (если сами схемы, конечно, есть).

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

Было допущено две ошибки:
1. Был придуман свой формат хранения структурированных данных.
2. Для его разбора были использованы регулярки.

Можно было бы хранить данные в csv, json, xml или в чем-нибудь еще — трудозатрат на разбор стало бы меньше. Что само по себе, естественно, не делает набор обычных файлов полноценной БД со всеми вытекающими.

Сообщение от daslex Так что сейчас если кто-то хочет дать рекомандации, то я бы посмотрел на рекомендации работы с БД в С++

Определиться с базой, выбрать библиотеку: Awesome C/C++: Database.

0

0

Сообщение от 0x10 Было допущено две ошибки: 1. Был придуман свой формат хранения структурированных данных. 2. Для его разбора были использованы регулярки.

Это сообщение в мой адрес?
Я обдумал и понял и сам пишу, что свой формат - садизм по отношению к себе.

Кем допущены? Мною такие варианты были обдуманы, хотя мне и писали: "хватит думать", но не проделаны. Под кодингом я имел ввиду кодирование своего формата хранения. Это же тоже подвид кодинга.
________________

Сообщение от gru74ik Значит, время переезжать в другой раздел.

Делать на С++ и ориентироваться на что-то - это очень разные ситуации.
Я делаю на С++, а опыт изучения других языков говорит в пользу чего делать выбор. Это могут быть БД и могут быть готовые форматы (json,csv,xml). Хотя у меня есть один вопрос относительно готовых форматов и бд, только здесь ему точно не место.

Мой маленький, живущий своей жизнью мир будет написан на С++ и работать в маленьком консольном окошке. (если у меня получится, конечно довести его до ума). Не торопитесь с выводами, друг мой.

0

Сообщение от daslex Не торопитесь с выводами, друг мой.

Зря перенёс в ООП?

0