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

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

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

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

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

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

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

@Nosey · 18.01.2016, 20:11

daslex,
Если честно, то я ничего не понял из вашего сообщения

Что вас не должно удивлять

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

Я хочу сказать вам вот что:
- Если вам нужен модуль - создайте его.
- Определитесь что он должен делать. !!
- Определитесь с кем он должен это делать. !!
- Напишите это

отвечая на вопрос "На каком уровне абстракции у меня достаточно данных для работы модуля".

Кликните здесь для просмотра всего текста

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
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
// Кто может спрашивать оценки.
// Понятия не имею что за поля тут могут быть в вашем случае, но тип лишним не бывает :)
class IGradePermissionTarget
{
public:
    virtual ~IGradePermissionTarget()
    {
    }
};
 
// Кто может рассказывать о своих оценках
class IGradePermissionOwner
{
public:
    virtual bool checkPermission(const IGradePermissionTarget& target) const = 0;
    virtual ~IGradePermissionOwner()
    {
    }
};
 
// :)
class Student: public IGradePermissionOwner, public IGradePermissionTarget
{
    std::vector<IGradePermissionTarget*> family_ { };
public:
    bool checkPermission(const IGradePermissionTarget& target) const override
    {
        return &target == this || std::find(std::begin(family_), std::end(family_), &target) != std::end(family_);
    }
 
    ~Student()
    {
    }
};
 
// Интерфейс модуля проверяющего возможность выдачи оценки.
class IGradePermissionChecker
{
public:
    virtual bool hasPermission(const IGradePermissionOwner& owner, const IGradePermissionTarget& target) = 0;
    virtual ~IGradePermissionChecker()
    {
    }
};
 
// Примерное поведение модуля проверяющего возможность выдачи оценки.
class GradePermissionChecker: public IGradePermissionChecker
{
public:
    bool hasPermission(const IGradePermissionOwner& owner, const IGradePermissionTarget& target) override
    {
        return owner.checkPermission(target);
    }
};
 
// Использование.
class MagicProffesorModule
{
    std::shared_ptr<IGradePermissionChecker> gradeChecker_;
public:
    explicit MagicProffesorModule(std::shared_ptr<IGradePermissionChecker> gradeChecker)
            : gradeChecker_(gradeChecker)
    {
    }
 
    void doWork()
    {
        Student stud;
        gradeChecker_->hasPermission(stud, stud);
    }
};
 
int main()
{
    MagicProffesorModule module { std::make_shared<GradePermissionChecker>() };
    module.doWork();
}

@daslex · 18.01.2016, 21:02 **[ТС]**

Nosey,
Ясно. Сейчас я это объясню другим языком.

Изначально была цель: "Создать журнал".Да, просто создать журнал.

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

Сам по себе журнал не имеет никакого смысла до тех пор, пока он никому не нужен. Кому он нужен? А кто его вообще использовать станет?

Я начал пляски от профессора. Как наиболее активного пользователя, работающего с журналом. Чаще всего журнал у профессора, логично начать с него.

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

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

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

Но в ходе обсуждения этой темы получается, что чаще всего я задаю вопросы по взаимодействию объектов между собой. Я задумался: "А что если?". Пусть, например профессор сообщает результат. В моем маленьком абстрактном мире такое сообщение - это обычный возврат сообщения из функции. Так вот: "А что если кроме того, что сообщить результат, надо что-то доделать". Тогда возврат значения вообще не подходит. Но кроме этого как сообщить кому надо и как не сообщать кому не надо мне стало не понятно.

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

Клиент серверная модель. Обучение ведется онлайн. Профессор - сервер. Студенты - клиенты. Профессор ничего не знает о тех кто его смотрит. Он ведет открытый урок. Кто захотел, тот зашел и смотрит. Профессор озвучивает оценку, клиент ее подбирает. Но если клиент находится в бессрочном бане, то профессор оценки ему не сообщает, а сообщает, например, что ему тут нечего делать. (для простоты модели это сообщает профессор). Бан мог быть получен в ходе процесса урока, поэтому изначально студент мог пройти проверку на посещение, ответить на вопрос и получить оценку. После того как получил оценку, он начал дико безобразничать. Профессор обиделся и не хочет ему отвечать. Хотя другим студентам сообщает оценку.

Вот что-такое.

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

IGPIGP · 18.01.2016, 22:21

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

Сам по себе журнал не имеет никакого смысла до тех пор, пока он никому не нужен.

Вопрос спорный. Дело в том, что придумать ненужную вещь невозможно. Всё что мы придумываем комбинирует и отражает реальность.
Сегодня не нужен, - через 100 лет его кто-то откопает. А если серьёзно, то спор о курице и яйце наиболее полезен как самодостаточный процесс. Удачная затея чтобы практиковаться в искусстве полемики. Говоря о том, что объект отражает ту часть реальности которая требуется программе мы правы. Но истина ещё и в том, что актуальность объекта определяется актуальностью его реального образа. Можно представить профессора с одной рукой, сжимающей златопёрый паркер. Но программа с таким профессором не сможет развиваться. Поглядите на классы в хороших библиотеках. Это монстры многообразия возможностей. И от того насколько они соответствуют реальным объектам зависит их применимость.
Напишите журнал который предоставляет возможность читать, писать, искать. Профессора напишите потом. Или кто-то напишет. Не важно знать, как выводится оценка, важно знать, что она как-то выводится.
Для организации урока и будет написан класс Урок. Он будет включать преподавателя, ассистентов, контейнер учащихся, контейнер посетителей (комиссии, представители учебной части, коллеги, стажёры). Он будет связывать вложенные поля и своими методами обеспечивать их взаимодействие. Например, он может информировать преподавателя, что при явке ниже 70% проведение данного занятия бессмысленно.
Только не надо оно Вам пока. Усложняя себе задачу Вы отодвигаете положительный результат во времени.
Если Дейтелы не пошли, ищите других. Их много. Но не стойте на месте, это не нужно.

@daslex · 18.01.2016, 22:58 **[ТС]**

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

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

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

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

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

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

Дело в том, что придумать ненужную вещь невозможно

Малевич придумал черный квадрат...

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

через 100 лет его кто-то откопает.

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

не имеет никакого смысла до тех пор, пока он никому не нужен

через 100 лет он стал нужным, значит приобрел смысл. Я разве не так сказал?

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

Поглядите на классы в хороших библиотеках

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

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

Не важно знать, как выводится оценка, важно знать, что она как-то выводится.

Такое ощущение, что мой вопрос понял только 0x10 и понял-то его постольку-поскольку я смог его тогда объяснить.

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

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

@ct0r · 19.01.2016, 00:18

daslex, хорош страдать уже. Слишком много думаешь.
1) Ставишь функциональные и нефункциональные требования.
2) Отводишь два часа на продумывание архитектуры. Не больше! Получаешь общее видение структуры и принимаешь ключевые решения, влияющие на всю архитектуру.
3) Пишешь код, который решает задачу. При написании решаешь возникающие проблемы как можно проще. Потом думаешь о дальнейшем расширении системы. Понимаешь, почему написал быдлокод. Рефакторишь. Думаешь. Понимаешь. И так далее. После написания кучи быдлокода придет понимание, почему он все же быдлокод, как лучше всего проектировать при изменяющихся требованиях и в этом роде. От этого больше пользы, чем если ты изначально продумаешь все идеально и так же идеально напишешь (без ошибок не наработаешь ни опыт, ни интуицию).

IGPIGP · 19.01.2016, 01:05

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

Малевич придумал черный квадрат...

Черный квадрат это самое простое изображение отсутствия света "в конце тоннеля" минималистскими средствами - белый лист + чёрный карандаш. Авангард, это несколько абстрактная штука, но вполне досягаемая. Я не фан Малевича, если очень мягко говорить, но чёрному квадрату отдаю должное. Не понимаю тех, кто хором повторяет то, чего не понимает. Так все ругают этот квадрат. Но дело же не в нём, а в духовном и эстетическом состоянии человека, в тот момент когда он решил это изобразить.

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

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

речь не о приёмах и алгоритмах, а о моделировании. Объект в программе отражает объект внешнего мира. Если в сущности "птица" вам понадобилось только левое крыло, то может и не нужен такой класс. Это не центральная сущность программы тогда и говорить о ней не имеет смысла в плане UML. Впрочем, ct0r, коротко и ясно сказал.

@daslex · 19.01.2016, 01:44 **[ТС]**

Я все-таки получаю опыт в ООП, а не рассматриваю классы. ООП интересно само по себе не в отдельной его части, такой как класс, а в поведении и взаимосвязях. (мне интересно, по крайней мере пока ещё интересно). Я так воспринял ООП по ходу развития своей модели, что именно когда все собирается воедино, именно тогда и понимаешь смысл существования ООП вообще.

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

Квадрат я не ругал. То только-лишь мое мнение, которое на мнения других личностей влиять вообще не должно.
Можно другой пример привести. Фонарик, работающий от очень яркого солнца только в идеально ясную, в идеально светлую погоду от Солнца. Он по сути никому не должен быть нужен.

UML мне нужно было только чтобы как-то обозначить систему. Сам по себе UML мне не нужен. Я использую свой стиль рисовки.

Заглядывая в

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

Поглядите на классы в хороших библиотеках.

тут палка о двух концах. Я в смысле опыта дизайна и архитектуры для самого первого опыта.

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

Не по теме:

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

Пишешь код, который решает задачу

когда у меня в шланге заработает std :: put_time начну писать. честно.

IGPIGP · 19.01.2016, 02:22

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

Я все-таки получаю опыт в ООП

Да нет уж, пока до ООП дойти надо и с ОП познакомиться. Как же без классов? Остальные "я" не стану обсуждать. Дело ваше.

@0x10 · 19.01.2016, 07:16

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

2) Отводишь два часа на продумывание архитектуры. Не больше! Получаешь общее видение структуры и принимаешь ключевые решения, влияющие на всю архитектуру.

Хотел бы сделать акцент на этом пункте. Не нужно продумывать каждую мелочь: достаточно проработать только те моменты, которые в дальнейшем будет слишком сложно изменить. Как узнать, что изменить легко, а что сложно? Долгий и надежный способ (об этом уже говорили) — метод проб и ошибок. Навскидку можно сказать, что изменениям наиболее сложно поддаются вещи, затрагивающие несколько систем: интерфейсы, протоколы, соглашения, форматы, зависимости. Как из реализовывать, чтобы проблем было меньше? Можно начитаться книжек по архитектуре, можно пробовать и ошибаться, можно и то, и другое.

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

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

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

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

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

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

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

IGPIGP · 19.01.2016, 10:41

Ну то есть на каком бы носителе и языке не был написан журнал его внутренняя сущность - таблица с парой координат id, DATA, где id уникален. Значение - "был", "не был", "5"...
Причём id - это не Ф.И.О а индекс (косвенность) в каком-либо списке. Именно в этом смысле не столь важно, что Вы храните. Важно к чему обеспечиваете доступ и в какой форме получаете.
Не может же профессор написать в деканат докладную (глаголы - словами, остальное числами):

Господин декан, ставлю Вас в известность, что 32 числа, студент 87 получил 6-ю оценку 2 по предмету 1. Прошу принять меры.
С уважением, 3/12.

Наделе это будет выглядеть:

Господин декан, ставлю Вас в известность, что 1-го февраля, студент Прохор Сидоров получил 6-ю оценку "неуд." по предмету "Язык высокого уровня С++". Прошу принять меры.
С уважением, проф. Преображенский.

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

@mporro · 19.01.2016, 11:27

daslex
Позволю себе дать Вам несколько советов по построению приличной архитектуры.

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

ООП рекомендации, которые непосредственно следуют из общих рекомендаций:
i) Избегайте локаторов сервисов и синглтонов. Они, в конечном итоге, приведут к неявным зависимостям. Используйте явное внедрение зависимостей в конструкторах.
ii) Старайтесь оперировать исключительно неизменяемыми объектами. Если объект изменяемый, он обязательно должен быть агрегирован каким-то окружением, которое явно конструируется при изменении объекта. Опять же, пока у Вас мало опыта, постарайтесь делать объекты неизменяемыми, т.е. объект и есть собственное окружение.

Несколько признаков хорошей ООП архитектуры, которые легко найти в исходном коде:
i) Хороший класс не содержит статических методов, по крайней мере открытых.
ii) Хороший класс содержит ровно один конструктор.
iii) Хороший класс либо не содержит данных, либо не имеет потомков.
iv`) Хороший класс наследует небольшому числу базовых классов.
v`) Хороший класс содержит небольшое число методов.
v`i) Хороший метод либо абстрактный, не содержит реализации, либо не является виртуальным, не может быть переопределён.
v`ii) Хороший неабстрактный метод состоит из одного выражения, которое стоит сразу за ключевым словом return.
v`iii) Хороший неабстрактный метод использует внутренние данные.

P.S.
Также стоит обратить внимание на важное свойство объектно-ориентированной архитектуры: Tell! Don't Ask.

Добавлено через 11 минут
P.P.S.
Пункт v`ii) следует воспринимать в более мягкой форме: хороший метод всегда возвращает результат ключевым словом return. Ещё луче, если метод можно описать одним выражением.

@daslex · 19.01.2016, 12:13 **[ТС]**

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

ii) Хороший класс содержит ровно один конструктор.

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

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

iii) Хороший класс либо не содержит данных, либо не имеет потомков.

Следовательно любой класс-родитель - фигня голимая.

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

Ну то есть на каком бы носителе и языке не был написан журнал его внутренняя сущность - таблица с парой координат id, DATA, где id уникален. Значение - "был", "не был", "5"...

Я сейчас уже думаю о журнале. Не как о классе в языке, а как о хранилище на диске. Придумываю себе способ хранения данных. А сам класс журнал будет оперировать с этим хранилищем. Конечно все сводится к БД, но я не могу пока понимать СУБД, это пока что моя забота. Это же тоже модель поведения и взаимосвязи.

Пока что я сам над этим думаю.

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

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

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

@Nosey · 19.01.2016, 12:45

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

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

(1) Для каждого класса? Тогда ещё операторы присваивания сделайте, для класса который из умного указателя не вылезет

Если у вам один класс - можно и написать, но когда их >200

, то лучше делать всем по дефолту =delete; а потом уже если на самом деле потребуется реализовать, то подумать, ещё подумать и реализовать.

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

Следовательно любой класс-родитель - фигня голимая.

Это был намёк на использование интерфейсов (Абстрактных классов).

(1) + не забываем о срезке.

@daslex · 19.01.2016, 13:06 **[ТС]**

Рано мне пока еще об этом думать. Когда намёк идет намёком легко все неумышленно переврать в последствии. Тут и так-то не все понятно, чтобы понимать намеки, понимать непонятные термины.

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

@rikimaru2013 · 19.01.2016, 13:32

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

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

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

А лучше бы: класс Mark с explicit конструктором )

читать такой код легче

C++
1
2
3
void updateMark( const std::string& name, Mark mark);
 
db.updateMark( "Ivanov", Mark(8) );

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

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

Еще совет - забей на UML

а Вы в начале своих проектов рисуете UML ?

@Kastaneda · 19.01.2016, 13:38

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

А лучше бы: класс Mark с explicit конструктором )
читать такой код легче

Легче, чем что? Чем трехэтажный template, да, легче

Но GRADE_1, читается не сложнее, чем Grade(1).
Необходимость использовать именно enum конечно же условность, но в общем случае, как сказали выше, больше и не надо. Плюс если стоит вопрос быстродействия, то enum быстрее.

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

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

а Вы в начале своих проектов рисуете UML ?

UML видел 2 раза в жизни - в универе и в одном из рабочих проектов заказчик свой UML дал, которые ему аналитика разработали. Все архитектурные решения пишутся на столовых салфетках

@ct0r · 19.01.2016, 13:47

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

а Вы в начале своих проектов рисуете UML ?

Чтоб я рисовал UML?

Не было такого

Все маркерами на досках, а потом фоткается)

@Nosey · 19.01.2016, 13:56

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

Рано мне пока еще об этом думать. Когда намёк идет намёком легко все неумышленно переврать в последствии. Тут и так-то не все понятно, чтобы понимать намеки, понимать непонятные термины.
Проблема в том, что подобные советы проскакивают слишком рано. Им место на этапе кодирования. Но я же еще и за код-то не взялся, чтобы их обдумывать. А когда возьмусь, то если даже просто вспомню о том, что где-то я видел что-то такое, то уже даже это само по себе хорошо будет.

Так начните кодить, вроде же со шлангом разобрались?

И касательно пунктов приведённых mporro, следование этим пунктам позволяет вам вообще отключать к чертям мозг когда прогаете

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

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

А лучше бы: класс Mark с explicit конструктором )

Если нужно - конечно, я бы и написал

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

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

@daslex · 19.01.2016, 14:11 **[ТС]**

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

Так начните кодить, вроде же со шлангом разобрались?

Когда это? Как шланг вредничал, так и вредничает (clang++)

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

Так начните кодить, вроде же со шлангом разобрались?

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

Я думаю о БД. Это не то, что можно понять за 5 сек. С БД я испытываю некоторые трудности.
Я собираюсь хранить где-то таблицы ==> Я собираюсь использовать БД. Как бы я не отбрыкивался, меня все равно к ним уведет. Я не понимаю БД. Но ищу связь ((С++) + (БД)).

Не надо думать, что я ною. Это отображение моей мысли на текущий момент времени. Из-за постоянных тем: "Сделайте мне за меня" можно ведь и априори неправильно о мне думать, как о ноющем и канючащем балбесе.

@mporro · 19.01.2016, 14:30

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

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

обычный, копии, перемещения

Конструктор копирования -- это, как раз, особая ситуация С++. Прежде, чем такой класс пустить в проект, нужно задать себе несколько вопросов.
Нельзя ли избежать собственного конструктора копирования какими-то библиотечными средствами?
Нет ли у Вас опасного побочного эффекта, который Вы упустили и пришлось писать конструктор копирования?
Если сложный побочный эффект есть, то немедленно проверить оператор присваивания и деструктор.

Эти вещи лежат далеко за пределами ООП. Здесь следует обратиться к эффективному использованию именно С++, к книгам Герба Саттера и Скотта Мейерса.

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

Следовательно любой класс-родитель - фигня голимая.

Возможно, Вы неправильно поняли конструкцию "либо, либо", которая часто используется в математике. Это нечто вроде "исключающего или". Либо A, либо B -- означает, что А и B не существуют вместе и хотя бы одно из них точно существует. Т.е. если класс содержит внутренние данные, то у него нет наследников -- он не родитель.
Если класс не содержит внутренних данных, то у него обязательно есть наследники.
И опять же, это рекомендации. Если правило не соблюдается, нужно провести ревизию кода. Существует опасность того, что Вы либо унаследовались там, где нужно было делать агрегацию, либо создали несущественную абстракцию.

Добавлено через 14 минут
daslex
Ещё соблюдение некоторых формальных правил, даже если это требует усилий над собой, очень помогает понять на практике, как это объектное ориентирование устроено. То, что кажется поначалу очевидным с точки зрения процедурного подхода, может быть сложно реализовать в рамках таких строгих правил. Зато со временем Вы натренируетесь сразу понимать, каким образом ту или иную задачу можно представить объектами, а не функциями. Пострадав при обучении, в бою Вы уже не будете думать куда воткнуть метод или где применить наследование, Вы просто будете идти ясным маршрутом делая поправки на детали языка и проекта.

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

Новые блоги и статьи Все статьи Все блоги /
GitHub Copilot в JetBrains: модель по умолчанию, Fix и контроль MCP and_y87 12.10.2026 10 октября 2026 года GitHub обновил Copilot для JetBrains: добавил настройки стартовой модели, исправления из диагностики и управление автозапуском MCP. Поддержка IDE 2025. 1 прекращена — требуется. . .	День 5 из 28: Codex подсказывает следующий запрос and_y87 12.10.2026 9 октября 2026 года OpenAI запустила бету Composer predictions — подсказок следующего сообщения в текущем диалоге Codex. Это помощь с формулировкой запроса, а не автоматическое продолжение задачи. . . .	Запустил конкурс "тем и промптов для текстовых квестов созданных почти чисто ИИ" Adler 06.10.2026 Всем привет! За последние три-четыре дня я создал более 16 текстовых квестовых игр используя преимущественно по одному запросу к ИИ на игру. Мне так понравилось смотреть все ветки/ сцены во всех. . .	ИИ не может найти нужный язык в списке 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. Приложение прошло модерацию и теперь доступно для скачивания. Делал его сам, шаг за шагом — и вот,. . .

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

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

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,886
	18.01.2016, 21:02 [ТС]
	Nosey, Ясно. Сейчас я это объясню другим языком. Изначально была цель: "Создать журнал".Да, просто создать журнал. Смысл был в том, чтобы изучить некоторые элементы ООП парадигмы. Ну не понравился мне подход Дейтелов. Хотя они просто упростили для выдачи материала свои идеи. Хотел бы я борщ, который сам готовится, сам газ включает и сам мне в тарелку наливается. Сам по себе журнал не имеет никакого смысла до тех пор, пока он никому не нужен. Кому он нужен? А кто его вообще использовать станет? Я начал пляски от профессора. Как наиболее активного пользователя, работающего с журналом. Чаще всего журнал у профессора, логично начать с него. Я стал описывать модель поведения профессора. Я ее почти закончил. Но в каком-то моменте задался вопросом развития. Я уже ранее писал о том, что у меня что-то похожее на модель реального мира. Конечно, я не переношу реальный мир в мир кода, но тем не менее я переношу эквивалент процесса реального мира в мир кода. В настоящий момент я не планирую создавать многопользовательскую систему. Но этот мой вопрос - это вопрос взаимодействия объектов в многопользовательских системах (я так пока что понял, хотя кто его знает). Взять, например профессора. Он сообщает результат. Сейчас я могу подобную озвучку озвучивать в пустоту. Я так и сделаю. Это будет такое поведение, что кому надо - тот услышит. Но в ходе обсуждения этой темы получается, что чаще всего я задаю вопросы по взаимодействию объектов между собой. Я задумался: "А что если?". Пусть, например профессор сообщает результат. В моем маленьком абстрактном мире такое сообщение - это обычный возврат сообщения из функции. Так вот: "А что если кроме того, что сообщить результат, надо что-то доделать". Тогда возврат значения вообще не подходит. Но кроме этого как сообщить кому надо и как не сообщать кому не надо мне стало не понятно. Сейчас могут быть неточности в определениях. Но я попытаюсь смоделировать этого вида проблему насколько смогу. Клиент серверная модель. Обучение ведется онлайн. Профессор - сервер. Студенты - клиенты. Профессор ничего не знает о тех кто его смотрит. Он ведет открытый урок. Кто захотел, тот зашел и смотрит. Профессор озвучивает оценку, клиент ее подбирает. Но если клиент находится в бессрочном бане, то профессор оценки ему не сообщает, а сообщает, например, что ему тут нечего делать. (для простоты модели это сообщает профессор). Бан мог быть получен в ходе процесса урока, поэтому изначально студент мог пройти проверку на посещение, ответить на вопрос и получить оценку. После того как получил оценку, он начал дико безобразничать. Профессор обиделся и не хочет ему отвечать. Хотя другим студентам сообщает оценку. Вот что-такое. По большому счету в конкретной программе на тему "Учебный журнал" подобные фильтры не нужны. Меня просто заинтересовала такого вида проблема. 0

@ct0r Игогошка! 1801 / 708 / 44 Регистрация: 19.08.2012 Сообщений: 1,367
	19.01.2016, 00:18
	daslex, хорош страдать уже. Слишком много думаешь. 1) Ставишь функциональные и нефункциональные требования. 2) Отводишь два часа на продумывание архитектуры. Не больше! Получаешь общее видение структуры и принимаешь ключевые решения, влияющие на всю архитектуру. 3) Пишешь код, который решает задачу. При написании решаешь возникающие проблемы как можно проще. Потом думаешь о дальнейшем расширении системы. Понимаешь, почему написал быдлокод. Рефакторишь. Думаешь. Понимаешь. И так далее. После написания кучи быдлокода придет понимание, почему он все же быдлокод, как лучше всего проектировать при изменяющихся требованиях и в этом роде. От этого больше пользы, чем если ты изначально продумаешь все идеально и так же идеально напишешь (без ошибок не наработаешь ни опыт, ни интуицию). 5

IGPIGP Комп_Оратор) $Эксперт по математике/физике$ 9007 / 4708 / 630 Регистрация: 04.12.2011 Сообщений: 14,003 Записей в блоге: 16
	19.01.2016, 10:41
	Ну то есть на каком бы носителе и языке не был написан журнал его внутренняя сущность - таблица с парой координат id, DATA, где id уникален. Значение - "был", "не был", "5"... Причём id - это не Ф.И.О а индекс (косвенность) в каком-либо списке. Именно в этом смысле не столь важно, что Вы храните. Важно к чему обеспечиваете доступ и в какой форме получаете. Не может же профессор написать в деканат докладную (глаголы - словами, остальное числами): Господин декан, ставлю Вас в известность, что 32 числа, студент 87 получил 6-ю оценку 2 по предмету 1. Прошу принять меры. С уважением, 3/12. Наделе это будет выглядеть: Господин декан, ставлю Вас в известность, что 1-го февраля, студент Прохор Сидоров получил 6-ю оценку "неуд." по предмету "Язык высокого уровня С++". Прошу принять меры. С уважением, проф. Преображенский. Ну то есть, внутренне, фамилия и имя хранятся в единственном экземпляре, где-то вне журнала. Дело даже не в экономии памяти, а в том, что выходя замуж студентка может сменить фамилию, например. Да и студенту легче, так как ошибок в таких деликатных предметах, как фамилия и имя будет немного. Ведь если у студента перепутать начальные буквы имени и фамилии, то имя Срохор не покажется таким уж страшным. Не зацикливайтесь, пишите, рисуйте и... опять пишите и опять рисуйте. Движение это жизнь. 2

@mporro 306 / 101 / 18 Регистрация: 04.07.2014 Сообщений: 571
	19.01.2016, 11:27
	daslex Позволю себе дать Вам несколько советов по построению приличной архитектуры. Общие рекомендации: i) Избегайте всего неявного, особенно неявных зависимостей и неявных преобразований типов. ii) Избегайте побочных эффектов с неявным окружением. Пока у Вас мало опыта, вообще не позволяйте побочным эффектам покидать функции. ООП рекомендации, которые непосредственно следуют из общих рекомендаций: i) Избегайте локаторов сервисов и синглтонов. Они, в конечном итоге, приведут к неявным зависимостям. Используйте явное внедрение зависимостей в конструкторах. ii) Старайтесь оперировать исключительно неизменяемыми объектами. Если объект изменяемый, он обязательно должен быть агрегирован каким-то окружением, которое явно конструируется при изменении объекта. Опять же, пока у Вас мало опыта, постарайтесь делать объекты неизменяемыми, т.е. объект и есть собственное окружение. Несколько признаков хорошей ООП архитектуры, которые легко найти в исходном коде: i) Хороший класс не содержит статических методов, по крайней мере открытых. ii) Хороший класс содержит ровно один конструктор. iii) Хороший класс либо не содержит данных, либо не имеет потомков. iv`) Хороший класс наследует небольшому числу базовых классов. v`) Хороший класс содержит небольшое число методов. v`i) Хороший метод либо абстрактный, не содержит реализации, либо не является виртуальным, не может быть переопределён. v`ii) Хороший неабстрактный метод состоит из одного выражения, которое стоит сразу за ключевым словом return. v`iii) Хороший неабстрактный метод использует внутренние данные. P.S. Также стоит обратить внимание на важное свойство объектно-ориентированной архитектуры: Tell! Don't Ask. Добавлено через 11 минут P.P.S. Пункт v`ii) следует воспринимать в более мягкой форме: хороший метод всегда возвращает результат ключевым словом return. Ещё луче, если метод можно описать одним выражением. 2

@daslex 1373 / 596 / 199 Регистрация: 02.08.2011 Сообщений: 2,886
	19.01.2016, 13:06 [ТС]
	Рано мне пока еще об этом думать. Когда намёк идет намёком легко все неумышленно переврать в последствии. Тут и так-то не все понятно, чтобы понимать намеки, понимать непонятные термины. Проблема в том, что подобные советы проскакивают слишком рано. Им место на этапе кодирования. Но я же еще и за код-то не взялся, чтобы их обдумывать. А когда возьмусь, то если даже просто вспомню о том, что где-то я видел что-то такое, то уже даже это само по себе хорошо будет. 0