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

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

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

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

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

0

0

0

Сообщение от daslex Базы данных однозначно.

Уверены?
База данных это универсальность и горстка утилит. И именно утилиты главное в этом понятии. Без утилит boost::serialization будет такой же базой данных, разве что работющей быстрее ). И не забывайте что написал Kastaneda.
Так вот, нужны ли вам утилиты?

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

Не нужны тут регулярные выражения. Мной предложенный формат прост как бревно, стар как фикалии мамонта, с ним работали даже в критичных местах в те времена когда регулярки не были написаны на каждом заборе. Сам С++ использует у оператора >> по дефолту разделителем пробел, чувствуете?

Сообщение от daslex Рост веса структуры в файле провоцирует сложность поддержки такого интерфейса.

Не понимаю что это такое, если вы о сложности разработки, то тогда обратите внимание на С# там из коробки есть кодогенераторы для Web Servic'а, как сервера так и клиента. В других понятиях, этаже проблема присуща и другим технологиям.

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

Это так, да, универсальность.
Но у вас проект горит или вы учитесь? Я считал что второе.

Сообщение от daslex ST 1 {Ivanov Ivan} {18.08.1980}

Откуда в формате фигурные скобки? Зачем они? Вы пытаетесь оправдать использование регулярок?

Теперь почему я предложил именно такой формат, а не другой какой-то:
1) Обучение.
2) csv - Это одно и тоже собственно, разве что разделитель поменять.
xml, json - избыточны для данного случая и все библиотеки скрывают реализацию(см пункт 1), и (см пункт 3).
3) Предложенный формат отлично переносится в будущем как на реляционные БД, так и в бинарный формат. В отличии от xml json позволяющие использовать вложенные структуры, которые точно будут поюзаны если будут доступны, лень штука такая)).

Собственно третий вариант самый важный.
Итого: Лёгкость в реализации, отладке, лёгкость в переносе на другой формат или реляционную БД и опыт в велиспедопарсинге, как архитектурном, так и в реализации.

0

Сообщение от Nosey Но у вас проект горит или вы учитесь? Я считал что второе.

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

Лучше один раз научиться, чем миллион раз переучиваться.

Везде ли есть boost?
Базы данных везде где я был.
Как представлены файлы - прямая зависимость от системы. (это я к переучиванию), хотя тоже были везде где я был.

Сообщение от Nosey Откуда в формате фигурные скобки? Зачем они? Вы пытаетесь оправдать использование регулярок?

Нет. Это временное явление. Но где строки с пробелами, я бы убирать фигурные скобки или подобие их точно не стал За регулярки я не цеплялся ни разу. Журнал, который описали мне в указанном посте как отдельный набор классов, пишется от 5 до 30 минут (в виде ничего толком не умеющей сущности), даже если учитывать что кто-то может отвлекать. Чтобы с ним работать, он должен быть заполнен. Чтобы он был заполнен, надо его кому-то заполнить. Кому его заполнять? Конечно мне. Тот указанный пост к этому отношения вообще не имеет. Существует слишком много форматов хранения, чтобы вообще без опыта ориентироваться с выбором формата хранения данных.

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

Добавлено через 46 секунд
Строки с пробелами как в темах'

0

Сообщение от daslex Лучше один раз научиться, чем миллион раз переучиваться.

Ах, этот дивный идеальный мир

Сообщение от daslex Везде ли есть boost? Базы данных везде где я был.

Согласен и не согласен одновременно, иногда бывают ситуации, но очень редко всё-таки. boost это просто код, ограничения для его не использования это просто галочка в голове. Но тут и буст тоже "не нужен", он приведён как пример.

Сообщение от daslex Но где строки с пробелами, я бы убирать фигурные скобки или подобие их точно не стал

Тут сделайте в формате так чтобы строки с пробелами были только по одной на сущность и были последними. т.е. признак окончания будет - перенос строки, либо же binary style - предварительное указание длины строки.
Да и время лучше хранить в unixTime.

Сообщение от daslex Журнал, который описали мне в указанном посте как отдельный набор классов, пишется от 5 до 30 минут (в виде ничего толком не умеющей сущности), даже если учитывать что кто-то может отвлекать. Чтобы с ним работать, он должен быть заполнен. Чтобы он был заполнен, надо его кому-то заполнить. Кому его заполнять? Конечно мне. Тот указанный пост к этому отношения вообще не имеет

Извиняюсь, я не указал что ссылался на вторую часть сообщения, о том что БД не панацея, в том числе по производительности.

Я особенно против базы в данном случае поскольку мы в теме ООП, и за интерфейсом
Пару интересностей таки скроется, их стоит реализовать.

Сообщение от daslex Пытаюсь, конечно, осилить. Смотрю одно, второе. Но пока что мне только общее описание только встречается.

0

Сообщение от Nosey Ах, этот дивный идеальный мир

Вы скорее всего не так поняли. Под следующей цитатой маленькое пояснение.

Сообщение от Nosey Сам С++ использует у оператора >> по дефолту разделителем пробел

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

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

0