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

@daslex · Регистрация: 02.08.2011

Студворк — интернет-сервис помощи студентам

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

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

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

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

@Nosey · 15.01.2016, 22:17

daslex,
Во-первых, хороший и простой и жизненный вариант приведён мистером Kastaneda в третьем посте.
Но если развлекаться/извращаться в ооп, то:

Сообщение от daslex

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

Из всего этого я хочу вам напомнить о существовании в ООП не только физических сущностей(оценка, студент, профессор, дневник, группа, журнал, запись в журнале, лекционная аудитория...), но и поведенческих(посещение студентом аудитории, ответ студента...) которые уже в свою очередь и будут в идеальном ООП делать соответствующие записи.

Сообщение от daslex

Там говорится об ООП, но выглядит по крайне мере подозрительно, хотя бы тем, что оценки вводятся в "непонятно где" и непонятно кем (Сам журнал вводит в себя оценки) и там где вводит, там что-то с ними дальше и делает.

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

Сообщение от daslex

"непонятно где" и непонятно кем

Сообщение от daslex

что-то с ними дальше и делает

@daslex · 15.01.2016, 22:26 **[ТС]**

В варианте Kastaneda почему оценка enum?
У меня его вариант не получился. Чего-то там упущено.
Вопрос с которым я борюсь сейчас - инкапсуляция.

@Nosey · 15.01.2016, 22:36

Сообщение от daslex

В варианте Kastaneda почему оценка enum?

Потому что оценке больше не надо

Если желаете добавлять к оценке "2" - "Кидался бумажками в девочку за первой партой", то тогда заводите конечно класс, но мы же про студентов говорим, а не про подготовительную группу в яслях? ))

Сообщение от daslex

У меня его вариант не получился. Чего-то там упущено.

Там была идея, так что там ничего не упущено, для идеи

Сообщение от daslex

Вопрос с которым я борюсь сейчас - инкапсуляция.

Ну, тут можно пару книжек написать.

@daslex · 15.01.2016, 22:50 **[ТС]**

Сообщение от Nosey

Потому что оценке больше не надо

Ну и введите в enum значение с клавиатуры. Я с удовольствием посмотрю.
___________
Я подозреваю, что Вы не особо разобрались в моей ситуации.
1. Есть конкретный вопрос.
2. Есть конкретная задача.
3. Есть конкретные попытки.

Что мне не нравится в Ваших ответах
1. Разабстрагировывание. Мне дела нет ни до каких сущностей, пока я застрял в "скелете" программы.
2. Вы очень поторопились с ответами. Кроме отсыла на третий пост ничего полезного не увидел.
3. Ваши советы могут привести к тому, что слабохарактерный человек разочаруется в ООП и смысле жизни. Плохо.

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

IGPIGP · 15.01.2016, 22:52

Сообщение от daslex

я борюсь сейчас - инкапсуляция

Инкапсуляция победит (имхо).
daslex, кот Frisky, это же начало. Потом нужно пробовать более сложные вещи. А сразу с журнала начать, это не оптимально. Представьте, что начинающий художник бьется над проблемой игры света в волнах у Айвазовского.
В принципе то, нужно ответить на вопросы:
1. Что из себя представляет журнал как набор существенных признаков с точки зрения вашей программы и Вы получите свойства, - набор данных. Если Вы не знаете структур, то это бесполезно.
2. Что должен уметь делать журнал (что делает - глагол)) и Вы получите набор методов. О функциях тоже знать уже нужно. Обдумывая методы - начните с прототипов и сразу может выяснится, что какие-то свойства нужно добавить.
Нельзя проектировать сложный класс без подготовки и практики. Начните с экзаменационной ведомости может?
А вообще начинают вхождение в тему с таких классов как Точка, Треугольник и кошаки всякие не случайно. Слово парадигма пока не поможет.

@Nosey · 15.01.2016, 23:14

Сообщение от daslex

Ну и введите в enum значение с клавиатуры. Я с удовольствием посмотрю.

А это как-то относится к архитектуре? И вы попробуйте ввести класс с клавиатуры и посмотрите, и потом найдите пару отличий от чтения энума:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
enum Grade
{
    ZERO, ONE, TWO, UNDEF
};
 
std::istream& operator>>(std::istream& stream, Grade& target)
{
    int gradeInt;
    stream >> gradeInt;
    if (gradeInt >= Grade::UNDEF)
    {
        stream.setstate(std::istream::failbit);
        return stream;
    }
    target = static_cast<Grade>(gradeInt);
    return stream;
}
 
int main()
{
    Grade grade;
    std::cin >> grade;
    std::cout << static_cast<bool>(std::cin);
    return 0;
}

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

IGPIGP · 15.01.2016, 23:31

Сообщение от Nosey

куда засунуть поведение

Есть хорошее местечко, если журнал иметь ввиду. Дело в том, что у журнала, практически нет поведения. Это хранилище и всё. То есть методы доступа get\set - покрывают все потребности. А среднюю оценку и посещаемость пусть профессура вводит. Пользуясь интерфейсом.

@daslex · 15.01.2016, 23:51 **[ТС]**

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

1. Что из себя представляет журнал как набор существенных признаков? - Что-то такое, куда записана информация. Всё. Я знаю структуры. Проблема не в них.

2. Что должен уметь делать журнал? -
а) Поиск информации. Журнал кроме как для поиска информации в реальном мире не нужен. Можно, конечно, пожар из него устроить, скормить плохому студенту, на самолетики пустить. Меня интересует только поиск в нем информации.
б) Сохранение информации в единицу трансляции (больше чем массив подходит).
в) Больше ничего.

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

Экзаменационная ведомость - простой массив объектов одного класса? Это вообще не сложно (мне). В ином случае (не массив объектов) все превращается в мой журнал.

Добавлено через 9 минут

Не по теме:

Для решения таких проблем описаны паттерны.
Тут другая проблема. Чтобы понять паттерны лучше всего сначала наступить на граблю. Я сейчас наступаю на граблю.

Добавлено через 2 минуты
Проблема не в "Куда засунуть поведение", а в том "Как связать" два независимых класса.

@Nosey · 16.01.2016, 00:31

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

Есть хорошее местечко, если журнал иметь ввиду. Дело в том, что у журнала, практически нет поведения. Это хранилище и всё. То есть методы доступа get\set - покрывают все потребности. А среднюю оценку и посещаемость пусть профессура вводит. Пользуясь интерфейсом.

Тут, намой взгляд, кто будет вводить - не существенно (либо хранилище, либо профессор), с точки зрения ООП неважно кто из моделей будет заниматься не своим делом

. А с точки зрения реального кода

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

daslex,
Я опять возьмусь за старое

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

Сугубо моё имхо в подходе проектирования:
1) В пень рисование УМЛ диаграмм, хотя честно на бою я их рисовать не пробовал

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

Сообщение от daslex

1. Что из себя представляет журнал как набор существенных признаков? - Что-то такое, куда записана информация. Всё. Я знаю структуры. Проблема не в них.

Это зависит от желаемого интерфейса использования.
Нпример:

Сообщение от Kastaneda

4. Класс Record (запись в журнале), может быть вложенным классом в классе Journal (см. ниже). Содержит объекты Student, Date, Grade, etc (по желанию можно добавить предметы и пр.)
4. Класс Journal - содержит массив объктов Record и методы для работы с ним.

Сообщение от daslex

2. Что должен уметь делать журнал?

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

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

Сообщение от daslex

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

А тут вообще всё убер просто - создать третий класс

Не по теме:

Как говорится "нет такой проблемы которую нельзя решить добавлением ещё одного уровня абстракции, кроме как слишком большого количества уровней абстракции"

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

1) Не бойтесь создавать сущности если они нужны.
2) Напишите уже скорее модель.
3) Сделайте для неё сериализацию.
4) Определитесь с интерфейсом взаимодействия пользователя.
5) Прикрутите пару абстракций, для красивого/удобного связывания (2) и (4).

@daslex · 16.01.2016, 00:55 **[ТС]**

Надо сразу правильно учиться. Это не та область, где стоит махать рукой на маленькие огрехи.
Мое мнение таково, что кто-то на инкапсуляцию смотрит как-то очень поверхностно что ли. (это не утверждение, это ощущение). Тыркать пальцами не буду, в тем более не могу отрицать, что в этом моменте могу быть не прав.
_________

Сообщение от Nosey

Определитесь с интерфейсом взаимодействия пользователя.

Проблема. К проблеме выдан совет создания доп. сущности. Не вижу возможных сущностей, связующих профессора и студента, исходя из действий работы программы (на рисунке красным текстом внизу).
2 и 3 не понял. Я не знаю что сие означает.

Рисунок никто не смотрел ведь. Признайтесь по хорошему. То, что тут мне советуете, там все это обрисовано. Это не столько UML диаграмма, сколько объясняловка (больше, конечно, самому себе).

IGPIGP · 16.01.2016, 00:59

Сообщение от Nosey

нет такой проблемы которую нельзя решить добавлением ещё одного уровня косвенного обращения

Дэвид Уилер.

В целом согласен. Лучше нагородить горбылей, а потом разгребать, чем буриданова дилемма.
Вообще, не стал бы я доверять выведение оценок журналу. Слишком он сух и черств (имхо). Я вижу в нём связную информацию о:
-посещаемости ;
-оценки.
То есть для каждой записи из списка студентов для данного предмета есть последовательность полей датированных занятий (попросту пар дата - клетка), где клетка может быть:
- " " пустой (был/делал вид что учится);
- "Н" (не был / делал вид что болел или честно филонил);
-"O" (обведенный кружком "Н" означает отработал. Не знаю как теперь, а у нас такое было).
- "цифра или число " в зависимости от шкалы - оценка.

Данные клетки должны разделяться итоговыми четвертными.
Кроме всего прочего у клетки могут быть дополнительные поля-описатели (желательно чтобы были) вроде - рядовое занятие, контрольная, лабораторная и т.п. эти атрибуты синхронны по дате (контрольная у всего класса одновременно бывает).
То есть надо разобрать, как это будет у Вас в проге работать. Тогда и появятся методы - дай количество пропущенных, долги, оценки сквозные, оценки по контрольным и пр.

@Nosey · 16.01.2016, 01:17

Сообщение от daslex

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

Всё просто, эта сущность вам нужна и в программе, и она даже существует в реальном мире - это "Высшее учебное заведение"/"кафедра"/"деканат" - выбирайте, либо можете их всех создать.
Профессор будет за журналом ходить в деканат.
В журнале уже будет предмет, список студентов и их оценок.

Сообщение от daslex

2 и 3 не понял.

Модель - сухие данные, с хорошой такой инкапсуляцией. Известно сего термина пошла из идеологии MVC/Модель Вид Контролер(гуглится на раз, прям вот щас

)
Сериализация - преобразование данных из одного формата в другой - в вашем случае операторы чтения и записи из/в потоки ввода/вывода соответственно.

Сообщение от daslex

Рисунок никто не смотрел ведь. Признайтесь по хорошему. То, что тут мне советуете, там все это обрисовано. Это не столько UML диаграмма, сколько объясняловка (больше, конечно, самому себе).

Вот честно смотрел секунд 20, но не понял по ней, кого не связываете за эти 20 секунд

Не по теме:

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

Дэвид Уилер

Это автор? Теперь буду знать :)

Добавлено через 4 минуты
daslex, Забыл указать, что профессор не должен на самом деле "ходить в деканат", профессор о деканате не должен знать, профессор - это просто маленькая модель, описывающая преподавателя.
"ходить в деканат" -это я абстрактно говорю ))))
Архитектурно, при начале урока нечто поведенческое должно "взять" из объекта "деканат" нужный "журнал", нужного "профессора", нужных "студентов" и начать проставлять "оценки".

@daslex · 16.01.2016, 01:18 **[ТС]**

Сообщение от Nosey

Высшее учебное заведение"/"кафедра"/"деканат

и правда. спасибо.

IGPIGP · 16.01.2016, 01:29

Не по теме:

Сообщение от Nosey

Это автор? Теперь буду знать

David Wheeler это как Иван Петров. Однако талантливые все. Футболист, режиссёр... Программист тоже классный. Я не читал, - далёк от ASM и С... Троелсен любит фразу которую Вы привели. У него впервые и прочёл. :)

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

@Nosey · 16.01.2016, 01:39

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

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

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

Не по теме:

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

IGPIGP · 16.01.2016, 01:46

Сообщение от Nosey

мне об этом напомнил

Нет. Это показалось. Я серьёзно считаю, что имеет смысл написать класс - занятие. Ведь занятие и может быть:
-лекция;
-практика/лаба
-тематическая контрольная;
-четвертная контрольная;
-годовая контрольная;
вроде всё пока.
Для каждого из них имеет смысл " ", "Н", "О"...
То есть у занятия группка наследников, например. Хотя можно и перечислением обойтись. Тут же непонятно какого уровня прога будет.

@daslex · 16.01.2016, 01:47 **[ТС]**

Я через некоторое время попробую с деканатом. Другие заботы пока что.

Я не планировал делать мегасистему. Это для учебных целей. Я же писал (смотреть первые два предложения в самом начале темы). Я планировал сделать скелет программы. Сегодня в мыслях было имитировать учебный процесс. Своеобразная автоматизация учебного периода. При правильном проектировании должно получиться.

IGPIGP · 16.01.2016, 01:51

Сообщение от daslex

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

Хех... Для правильного проектирования имеет смысл знать свойства строительного материала: кирпича, цемента, шпатлёвки... Иначе обломовщина всё (имхо).

@Nosey · 16.01.2016, 01:52

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

Тут же непонятно какого уровня прога будет.

Именно так, этого никто не знает

И никто и никогда не узнает какого уровня будет хоть одна прога в этом мире

И я никак не считаю что вы не правы. Напротив, если нужны разные занятия - обязательно их описать.

@ct0r · 16.01.2016, 01:54

Вы тут ведете речь не столько непосредственно об объектно-ориентированном программировании, сколько об объектно-ориентированном дизайне ( https://en.wikipedia.org/wiki/... ted_design ).
Я б советовал ознакомиться с SOLID ( http://butunclebob.com/Article... iplesOfOod ) и GRASP ( https://en.wikipedia.org/wiki/... ted_design ), почитать про Domain-Driven Design и паттерны проектирования.

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

Новые блоги и статьи Все статьи Все блоги /
Локальный http сервер Argus19 17.10.2026 Локальный http сервер На работе, на двух локальных компьютерах круглосуточно работают программы опроса приборов с записью в книги Excel,которые раз в сутки записываются на сервер компании. Т. к. . . .	Копировать Windows на новый диск на UEFI damix 17.10.2026 https:/ / uriesk. wordpress. com/ 2016/ 11/ 01/ move-window-10-to-ssd-on-a-uefi-dualboot-system-with-basic-linux-tools/ TL DR Вставляем диск, а старый подключаем через переходник, грузимся с лайва. . .	ИИ не может найти нужный язык в списке Supersumestria 05.10.2026 Я ему даю вот такое изображение и прошу найти и подчеркнуть немецкий язык. Возвращает он вот это: https:/ / i. **********/ vqBWLe2. png Нужную строчку в 3й колонке просто выдумал. . Это. . .	Новая последняя моя музыка в SUNO zorxor 05.10.2026 Здравствуйте, дорогие мои друзья! С большой радостью я хотел бы представить вам свою новую последнею музыку, которую сгенерировала мне по моей просьбе нейросеть SUNO. С уважением, zorxor. Это. . .
Программный домашний кинотеатр russiannick 27.09.2026 Сподобился на программный домашний кинотеатр. В качестве ЯВУ по традиции выбрал js. В помощники взял Яндекс-Алису. Было создано три зала на разные интересы. исторические и ретро сериал Хичкок. . .	Беседа с ИИ о программистах, недопускающих к созданию и правке кода генеративные ИИ и причины этого zorxor 21.09.2026 Раньше я радовался или получал некоторые эмоции, пусть небольшие, но всё же, от самого процесса написания кода, рекомпиляции и запуска, видя постепенное развитие программы и прочее. А теперь лень. . .	Мобильное приложение ColorStep pavlinmavlin 17.09.2026 Реализовал приложение Красный, Зеленый, Синий в Unity3d + c#. Название изменил на ColorStep. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .	Запрет дублирования строк в табличной части Maks 13.09.2026 Реализация из решения ниже выполнена на нетиповом справочнике "Нормы ТО" с табличной часть "Виды ТО", разработанного в КА2, со следующими реквизитами: - ВидТО (СправочникСсылка. ВидыТО); - ВидГСМ. . .

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,886

	Объектно-ориентированное проектирование и дизайн приложений: взаимодействие, модели, системы, архитектура 21.12.2015, 06:52. Показов 8706. Ответов 125 Метки нет (Все метки) В общем, дело такое. В ООП ничего не понимаю. Нужны некоторые уточнения парадигмы. Предполагается чистый C++ (без boost, stl и подобного). Для примера: создание класса "журнал оценок". Двойки в который в детстве ставили многим. 1. Должен ли класс внутри себя хранить массив ФИО, Даты? Или не должен. 2. Не очень понятно как связать оценки, если должен. Я так понимаю, что класс все-таки должен хранить внутри себя массивы. Но это использовать неудобно, местами вообще непонятно (вопрос пересечений ФИО и Даты для получения оценки). Как это может стать удобным мой мозг догадываться наотрез отказался, уперся в то, что массивы надо создавать вне класса и обрабатывать их вне класса, а класс должен содержать только единичные значения. Это, с единичными значениями и внешними массивами, может и удобно, но так не получается такой объект, который как бы заимствован из нашего мира и спроецирован в мир приложения, а, значит, такое ООП - не ООП. Помощь нужна. Я именно в теории нуждаюсь. Примеры, конечно, тоже могут стать полезны, только сложных не надо. 0

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,886
	15.01.2016, 22:26 [ТС]
	В варианте Kastaneda почему оценка enum? У меня его вариант не получился. Чего-то там упущено. Вопрос с которым я борюсь сейчас - инкапсуляция. 0

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,886
	15.01.2016, 23:51 [ТС]
	Как объяснить себе я знаю. Почему другим объяснение мое непонятно для меня неизвестно. 1. Что из себя представляет журнал как набор существенных признаков? - Что-то такое, куда записана информация. Всё. Я знаю структуры. Проблема не в них. 2. Что должен уметь делать журнал? - а) Поиск информации. Журнал кроме как для поиска информации в реальном мире не нужен. Можно, конечно, пожар из него устроить, скормить плохому студенту, на самолетики пустить. Меня интересует только поиск в нем информации. б) Сохранение информации в единицу трансляции (больше чем массив подходит). в) Больше ничего. Начинать надо не с методов или прототипов, а с проектирования хоть на бумаге, иначе даже маленький проект превращается в огромную головную боль. Я уже сделал такой вывод. Экзаменационная ведомость - простой массив объектов одного класса? Это вообще не сложно (мне). В ином случае (не массив объектов) все превращается в мой журнал. Добавлено через 9 минут Не по теме: Для решения таких проблем описаны паттерны. Тут другая проблема. Чтобы понять паттерны лучше всего сначала наступить на граблю. Я сейчас наступаю на граблю. Добавлено через 2 минуты Проблема не в "Куда засунуть поведение", а в том "Как связать" два независимых класса. 0

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,886
	16.01.2016, 01:47 [ТС]
	Я через некоторое время попробую с деканатом. Другие заботы пока что. Я не планировал делать мегасистему. Это для учебных целей. Я же писал (смотреть первые два предложения в самом начале темы). Я планировал сделать скелет программы. Сегодня в мыслях было имитировать учебный процесс. Своеобразная автоматизация учебного периода. При правильном проектировании должно получиться. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	16.01.2016, 01:54
	Вы тут ведете речь не столько непосредственно об объектно-ориентированном программировании, сколько об объектно-ориентированном дизайне ( https://en.wikipedia.org/wiki/... ted_design ). Я б советовал ознакомиться с SOLID ( http://butunclebob.com/Article... iplesOfOod ) и GRASP ( https://en.wikipedia.org/wiki/... ted_design ), почитать про Domain-Driven Design и паттерны проектирования. Еще достаточно странно видеть попытку просто вот взять и перенести реальный мир в реализацию ООП на языке. Перед нами изначально должна стоять какая-то конкретная проблема, которую нужно решить. Тогда мы строим модель реального мира, но не абсолютно точную, а приближенную настолько, чтобы с ее помощью эту проблему можно было решить. А пока вы, как мне кажется, просто выбираете сущности наобум, без понимания зачем они вообще тут нужны - потому что четкой задачи нету, а есть ООП ради ООП. Может я неправ, но ощущение у меня такое. 4