Комментарии 81
Объект это не концепция реального мира. ... Надо прекратить думать в данном ключе!
А кто или что вообще заставляло вас думать в этом ключе? Это в манифесте какого-то языка заложено? Или у какого-то автора типа Шилдта постулировано?
По мне так это такой детский миф, живущий в джуновской среде. Только на джуновских собеседованиях я слышу про все эти "объекты реального мира", "наследование для переиспользования кода" и "Cat extends Animal". На практике принципиально другие вопросы задаются: "это работает?", "это тестируемо?", "это расширяемо?", "лучшим практикам не противоречит?" "это не антипаттерн?", "через месяц пойму, что написал?". Никто уже всерьез не упарывается экзистенциальным поиском святого Грааля ООП. Тем более, что почти все популярные языки давно уже мультипарадигменные.
По мне так это такой детский миф, живущий в джуновской среде. Только на
джуновских собеседованиях я слышу про все эти "объекты реального мира",
"наследование для переиспользования кода" и "Cat extends Animal".
Так вроде это используют, чтобы объяснить концепцию, человеку, который не знаком с ООП проще понять, что-то на реальных примерах, правда проблема в том, что ряд людей дальше понимания "Cat extends Animal" не заходят.
Эта мысль банальна или хороший совет?
Прекрасный вопрос. Даже затрудняюсь, как на него ответить :D
Хм, даже не знаю что сказать. Задолго до появления ООП в моей жизни я занимался структурным программированием, потом базами данных и как-то не возникало идеи данные внутри ПК ассоциировать с реальным миром. Позже, уже к концу 90-х столкнулся с ООП и я не увидел никакой необходимости что-то менять в понимании кода и структур данных и как-то их связывать в реальностью. По сути тока соприкосновения одна - и данные реального мира и данные в ПК - это закодированные данные, а система кодирования и раскодирования может быть весьма причудливая.
Конкретно по вашей статье - я не люблю ООП, я не чувствую оформленную таким образом программу структурно целой, для меня это куча разрозненных кусков кода который мечется от объекта к объекту. Но это чисто моя проблема. Но манипуляции с объектами, когда вы объединили три в один, на мой взгляд ничего не меняют абсолютно кроме стилистики оформления, ну и заставят вас писать более длинные названия методов.
Вообще странно что сама идея всё видеть в виде объектов пришла вам задолго после того как вы познакомились с ООП, я так мыслю с 1986 года когда сел программировать на Бейсике. Мир сразу стал другим.
Но манипуляции с объектами, когда вы объединили три в один, на мой взгляд ничего не меняют абсолютно кроме стилистики оформления, ну и заставят вас писать более длинные названия методов.
ИМХО, объекты упрощают понимание, но только при ассоциации с объектами внешнего мира. Например, когда я создаю объект "Pallet", то образно ассоциирую его с паллетом на складе, и дальше у нас идут свойства и методы - вес, объем, состав, сборный или целый, у него там есть заказчик, он позволяет поересчитать количество коробок на нем, запаллетировать\распаллетировать в системе. И это сильно упрощает работу- когда мне говорят, что еще надо учитывать, ADR паллет или обычный, то я добавляю свойство к объекту, а не вставляю куски кода в различные места, редактируя с ошибками индексы и переменные. Это понятно, потому что идет моделирование реального мира.
А создать объект ради объекта - это какой-то мазохизм или я что-то не понимаю в жизни.
Это всё давным-давно придумано уже. "Мнемоника" называется.
А как быть мне если я почти никогда не пишу код хоть как-то ассоциируемый с реальным миром? Ваши паллеты - это 1% темы. Да, удобно, но и очевидно, не вижу тут противоречий с моими словами. Это называется - прикладное применение.
Один из примеров, в 1992 году я делал курсовую на Clipper+DBF, за тему взял статью в журнале - кем я был в прошлой жизни. Там было 12 знаков зодиака, какие-то таблички с рунами, много всего. В итоге я сделал штук 7 таблиц, где происходила связь по ID, таблички были в виде ID, RUNE_ID, ZODIAK_ID. Связь с реальным миром была потеряна, кто-то не имеющий статьи из журнала не сможет восстановить информацию, так как будет только набор чисел.
Или когда пишешь игру на ассемблере - какая там связь с реальностью? Всё выдумка, а объектов сотни. Просто ваша работа связана с конкретными вещами, это как 1С-ники - у них деньги, товар и документы, других объектов нет.
про игру некорректно - игра моделирует реальность в первом приближении. Никто не может придумать ничего, чего бы не было в реальной жизни так или иначе. Свойства и взаимосвязи берутся так или иначе из пыта реального мира. Абсолютных абстракций не существует, разве только у шизофреников
Как много реальных Богов вы знаете? Как много антропоморфных инсектоидов? Или то что у Бога на изображениях лицо человека, то вы считаете что это модель реальности?
Математика - это способ описать и понять мир и с реальностью оно вообще никак не связано, это абсолютная абстракция придуманная человеком. Именно так человек и программирует - создаёт абстракции, которые описывают другие абстракции, на выходе - да, это может быть информация применимая в реальности, а может и не быть.
Если так не понятно - вот пример - изображение. Фотоны попадают в глаза, регистрируются и в виде импульсов (закодированная информация) попадают в мозг, где декодируется и формируется изображение, которое отчасти соответствует реальности. Если рядом с глазами вы поставите камеру, то для регистрации фотонов у вас будет или пластина (пленка) которая будет менять химически молекулы (кодировать), а потом вы сможете изображение восстановить. Оба способа - импульсы и химия - это способы кодирования в абстрактную сущность - изображение. Почему она абстрактная - потому что есть убрать камеру и человека то объекты, отражающие или испускающие фотоны не перестанут этого делать (вопрос наличия наблюдателя и его влияния на систему мы обсуждать надеюсь не станем).
Для обработки изображения я создам класс Picture в ней объект Raw и методы getPixel, setPixel например - что из этого хоть какое-то отношение имеет к реальности? Это всё абстракции в попытке моделировать объекты из реальности. Pixel - это не объект реальности, как и матрица с сырыми данными Raw.
я бы предложил вам почитать о том что такое информация и кибернетика.
То, что вы открыли для себя, называется декомпозиция. ООП (и объекты в частности) — это один из способов реализации декомпозиции. Этот способ является лучшим далеко не всегда, но это зависит от языка программирования. ООП можно использовать не только для моделирования реального мира, применение ООП ограничено только фантазией программиста.
Часто код будет намного понятнее, если сделать просто функцию вместо класса. Класс со статическими методами — ок, когда в языке не удобно работать с простыми функциями. Объект с обычными методами имеет смысл, когда он хранит внутри себя некоторое состояние или зависимости.
1. Если требуется несколько сложное состояние, инвариант, в этом случае требуется объект, который и будет поддерживать это состояние через внешний интерфейс, в строгой согласованности.
2. Также объект может быть полезен, если некие данные абсолютно независимы друг от друга, могут меняться не согласованно, но по логике очень часто передаются вместе. Частный случай — структура.
Во всех остальных случаях функции предпочтительнее и гибче, на мой взгляд.
применение ООП ограничено только фантазией программиста
Это вроде называется абстракция, принцип ООП, о котором почему-то постоянно забывают.
In Python, everything is an object.
Я питонист конечно не настоящий, но не раз слышал, что In python everything is an object.
Запускаю repl, что же я там вижу:
>>> class
File "<stdin>", line 1
class
^Чьёрт побьерьи! Я ожидал увидеть что-то вроде:
>>> class
<class 'class.Class'>Та же фигня и для if def return = \n \. \, ну и много ещё для чего.
То есть если простыми словами — то, что вы вы написали в вашем примере, до самого питона вообще даже не дошло.
Это как если бы мы сказали, что в русском языке всё является одной из десяти частей речи, а кто-нибудь привёл бы в качестве контрпримера "!№;%:?*()", заявив, что раз оно не является ни одной из 10 частей речи, то наше утверждение не верно.
Тогда может неправильно говорить, что все сущности языка являются объектами, если существуют такие сущности, которые не то, что не объекты, а даже в аст не парсятся?
если существуют такие сущности
Вот только это и не сущность языка.
Если что-то не является корректной и законченной синтаксической конструкцией, то вообще нельзя сказать, что с точки зрения языка оно чем-то является или не является.
Так-то действительно существует куча вещей, которые не являются объектами питона. Например, галактика Млечный Путь, или запах розы, или роса на траве. Они не объекты питона, но это только потому, что они вообще лежат за пределами питона. Ровно так же, как и некорректные синтаксические конструкции.
Зарезервированные слова языка не являются его сущностями? Ну извините.
Операция плюс '+' сама по себе тоже не является законченной грамматической конструкцией, и сама по себе правильно для аст не распарсится. Однако же объектом является, и ее можно передать как аргумент функции, например. А зарезервированное слово class не является объектом, и как аргумент функции его не передашь, а ведь можно было бы и передать. Например, передавая зарезервированные слова как аргументы можно было бы их как то конкатенировать друг с другом и получать уже законченные конструкции. Ан нет!
Ведь если уж кто то заявляет, что всё есть объект, то уж хотя бы зарезервированные слова должны быть объектами.
Однако же объектом является, и ее можно передать как аргумент функции, например.
Нет, плюс не является объектом, и нет, его нельзя передать в функцию. Вы бы хоть проверяли те фантазии, которые приходят вам в голову, прежде чем высказать их как факт.
Ведь если уж кто то заявляет, что всё есть объект, то уж хотя бы зарезервированные слова должны быть объектами.
С чего бы это вдруг? Вы вообще понимаете разницу между элементами синтаксиса языка и сущностями рантайма?
Давайте ещё раз. Утверждение "в питоне всё есть объект". Контрпример - зарезервированное слово class. А это другое надо понимать, class не является законченной грамматической конструкцией и в аст не парсится.
Вопрос: если все есть объект, то почему class не является законченной грамматической конструкцией?
Как я вижу он вполне себе мог бы быть законченной грамматической конструкцией и объектом - таким объектом у которого мог бы быть метод concat(), чтобы объединив его с другими объектами получить другую грамматическую конструкцию - аналогично частично применненной функции. Но он таковым не является. Значит всё, да не не всё.
З.Ы. Я сразу написал, что питонист не настоящий. И каюсь, я был уверен, что + это точно объект. Ну если нет, то это вообще цирк. Одна из самых часто используемых функций не является объектом. Рука-лицо!
Давайте ещё раз. Утверждение «в питоне всё есть объект». Контрпример — зарезервированное слово class.
С чего бы это является контрпримером? Если вы пишите просто «class», то это вообще не является корректной программой на питоне. У вас будет просто ошибка синтаксиса.
Как, чёрт возьми, контрпримером о питоне может являться то, что не является сущностью питона?
Я из утверждения "все является объектом" делаю однозначный вывод, что зарезервированные слова тоже являются объектом. И что функция языка питон + тоже является объектом. Ну по крайней мере по логике вещей так должно быть. Но у питона своя особакя логика.
Я из утверждения «все является объектом» делаю однозначный вывод, что зарезервированные слова тоже являются объектом.
Это исключительно ваша неверная трактовка. Элементы синтаксиса и сущности рантайма — это вообще разные вещи. Эдак можно требовать, чтобы клавиатура тоже являлась объектом — мы же питоновский код на клавиатуре набираем!
И что функция языка питон + тоже является объектом.
Символ плюса — это не функция.
Но у питона своя особакя логика.
Вы знаете много других языков, где элементы синтаксиса и сущности рантайма являются одним и тем же?
Пустой разговор.
Я прицепился к словам, думал будет забавно, получилось грустно.
Вы знаете много других языков, где элементы синтаксиса и сущности рантайма являются одним и тем же?
Проблема в том, что фраза "в питоне все есть объект" ормально скорее про элементы его синтаксиса, чем про сущности рантайма, ибо элементы синтаксиса таки в языке, а не где-то еще, а вот сущности рантайма уже не совсем в языке. И если кто-то утверждает, что в питоне все есть объект, то это формально однозначно означает, что элементы синтаксиса являются объектами.
Другой вопрос, что люди любят формально некорректные по смыслу высказывания для обозначения вполне корректных по смыслу вещей. Например, "в UNIX все есть файл", хотя там можно найти много всякого, что просто не может быть файлом.
А потому дискуссия ваша выглядит несколько забавно, но не более того.
SmallTalk
Переменная — не объект. Не то, на что она указывает, а сама переменная. if then else и прочие конструкции — тоже не объект.
Объект — это всё же программисткая концепция, развитие идей структурных типов.
Класс — это вообще из теории множеств, там всякие брадобреи и прочее (да, это программисткий термин восходит именно к математическому, так же как и лямбда-функции).
«Классическое» ООП, которое преподают на этом различии особо не заморачиваются, т.к. мейнстримовсие языки более-менее жалеют мозги программистов и прячут весь тот математический трип, на котором они построены за красивыми языковыми конструкциями.
Ну и да, непонимание тонкостей и истории понятий (ООП 60-х — это совсем не ООП сегодня) приводит к неумению грамотно пользоваться инструментом. Вроде с этим должны справляться наборы принципов вроде SOLID — но их тоже понимают в лучшем случае по-разному (если вообще хотят понимать). Вот и получаем, что на ООП-языках вроде JAVA, C#, Python люди пишут «на бейсике». Это можно поставить в вину языкам — что позволяют такое. Но всё же на любой Тьюринг-полной системе можно писать «на бейсике» (а можно и организовать ООП).
Это ни плохо, потому что программист — он инженер, а не учёный — ему вся эта матмуть справедливо до лампочики. Ему набор готовых велосипедов и техник езды на них нужен.
Но и не хорошо, т.к. погроммист скотина думающая (это я про себя) и начинает из этих велосипедов строить свою «мета-велосипедную» науку, накручивая сложности там где не надо.
https://wiki.c2.com/?AlanKaysDefinitionOfObjectOriented
И там дальше по ссылкам
По Хаскелю: я реально не спец в хаскеле, но почитываю иногда (с целью стырить какой-нибудь хороший подход). И вот окрываю я, например, такое, а там классы, классы, классы — это не то? Уже устарело / шаг в сторону? Я не ехидничаю, я реально не в курсе.
… отношение к классам в ООП примерно как у функторов из теорката к функторам в ML или в C++
Ну так дык, и у лямбда-функций отношение такое же: Т.е. это практическая реализация в конкретных алгоритмах абстрактной математической концепции (как и всякое воплощение идеала — от идеала далёкое)
Дальнейшее развитее этой темы приведёт к обобщённой дискуссии — что есть математика и программирование?
(Если интересно, моя позиция: математика (вся, любая) — наука о проведении вычислений и алгоритмах, программирование — практическая реализация мат. концепций в меру возможностей)
Вы же не прикалываетесь? Все вот эти сервисы, передавамые как аргумент функции? Это же треш! Это сервис типа стейтфул объект? Почему в статический класс передаются экземплры сервисов? Что это ваще?
// Количество рабочих часов на каждый день недели
public class UserSchedule
{
public float Monday { get; set; }
public float Tuesday { get; set; }
public float Wednesday { get; set; }
public float Thursday { get; set; }
public float Friday { get; set; }
public float Saturday { get; set; }
public float Sunday { get; set; }
}Жёстко.
// Количество рабочих часов на каждый день
public class UserSchedule
{
public float FirstOfJanuary{ get; set; }
public float SecondOfJanuary { get; set; }
...
public float ThirtyFirstOfDecember{ get; set; }
}Я надеюсь это просто учебный пример и в реальности автор использует производственный календарь
Так не очень понятно, что должен иллюстрировать этот учебный пример семи методов с одинаковыми сигнатурами и одинаковой логикой.
Я надеюсь это просто учебный пример и в реальности автор использует производственный календарь
Без шуток — я знаю (работал на) организацию, которая до сих пор использует в своём закупленном пропроитарном софте (от компании с мировым именем) рабочий календарь, который именно так и устроен. Буквально именно такая структура по дням недели.
Причём каждый год они «вручную» (естественно, я скрипт написал который они запускали) дозаписывают в БД на каждый день следующего года строчку в БД. И если немного провафлить (что было пару раз) — то у людей после праздников ничего не будет работать.
И я не могу сказать что это не оправданно — в той архитектуре такая схема была очень органичной.
Хотя да, когда с таким работаешь — просто чуствуешь, как в тебе отключается всё человеческое и ты просто исполняешь приказы. Ja, ja.
Вы движетесь в правильном направлении, но впереди у вас ещё долгий путь. Хотя в целом вы видимо освоили ООП и теперь можно уже начинать потихоньку учиться отказу от ООП.
У вас какой-то ограниченный язык программирования что всё приходится пихать в объекты (java).
В нормальном языке есть ещё модули, которые никак не связаны с объектами (golang)
Похожие функции надо было объединить в один модуль а не в один объект - фигнёй занимаетесь и других учите неправильно :-(
Ну частично не соглашусь с основным выводом.
Конечно объект - не обязательно сущность реального мира.
Технически это действительно набор полей и методов их обработки.
Но хороший объект - это все же хорошая абстракция.
Не стоит лепить все оставшиеся бесхозными данные и операции в отдельный класс только потому, что они в объекты плохо вписываются.
Поэтому нет проблем в объекте, который содержит данные процесса (то есть не сущности, а действия). Собственно есть целый паттерн "команда". И целая парадигма Data Context Interaction, направленная на представление операций в объектном стиле.
И, точно так же, многие вспомогательные объекты упрощают работу основных объектов, как виртуальные частицы в физике - их самих не существует, но они обеспечивают некоторое взаимодействие, зная про все объекты, участвующие в них.
Мне кажется автор очень верно поставил вопрос. В учебниках по ООП именно так и обучают программированию, учать классифицировать объекты реального мира, искать общие и уникальные свойства, на основе такой классификации разрабатывать иерархию классов, потом генерить на основе этих классов объекты и программа будет работать как множество этих объектов, взаимодействующих между собой. Иногда такой подход даже работает.
Но, ИМХО, НАСТОЯЩАЯ ПРАВДА в том, что есть разные типы задач. И для разных типов задач хорошо использовать разные архитектурные подходы. Соответствующий типу задачи подход позволяет упростить внутреннюю структуру программы, ее написание, отладку и модиффикащию.
Давайте разберем парочку примеров для конкретности.
1) Задача состоит в работе большого количества похожих сущностей, имеющих много общих свойств. Например графический интерфейс, или компьютерная игра. В таком случае более менее подходит описанный в первом абзаце традиционный подход с иерархией классов и объектами на основе этих классов.
2) Задача состоит из одного или нескольких больших массивов обрабатываемых данных и операций над ними. В таком случае возможно лучше подойдет просто испольование глобальных массивов данных и набора работающих с ними функций.
3) Случай 2) но с более сложными функциями обработки данных, с состояниями и т.д. Тут могут подойти объекты имеющие внутреннее состояние и работающие с данными. Но городить иерархию классов тут как правило не нужно.
4) Чисто вычисления на базе входных данных без внутренних состояний. Тут может подохти чисто функциональный подход.
5) И так далее...
Лично мой любимый метод использования классов в питоне - рассматривать и использовать класс и созданный на его базе объект как state machine. В простейшем случае два состояния, до инициализации и после инициализации.
Иногда питоновские классы я вообще использую просто как пространство имен.
Проблема ИМХО в том, что в книгах как правило проповедуется один любимый поход для всех классов задач.
Что касается одинаковой логики, используемой в разнородных классов, то мне кажется, что такую логику лучше выносить в отдельные функции.
Объект - это (всего лишь) данные и функции, ассоциированные с ними
Совершенно не так.
Объект - это осмысленно соединенные функции и данные. Объект в программе, естественно, не обязан отражать объект из реального мира (почему-то у меня и мысли такой не возникло, хотя учили, как и многих, на стандартных примерах про животных). В его основе может лежать любая абстракция. Но это не должно быть произвольным сочетанием функций и данных, которые связаны только тем, что в программе случайно оказались рядом.
Объект это не концепция реального мира
Объект это не концепция реального мира, это концепция модели реального мира.
Если, например, вы используете реляционную базу данных - поздравляю, у вас ООП. Структура таблицы - класс; строка таблицы - экземпляр класса.
Объект — это в первую очередь его поведение. Которое да, зависит от внутреннего состояния объекта. Но в идеале об этом состоянии извне никто не должен знать и никого оно не должно ни коим образом интересовать.
А строка в БД — это именно состояние. Это структура. А не объект.
На каждый блок с логикой (цикл, последовательность условий и т.д.) я смотрю с мыслью: “Нельзя ли вынести это в отдельный объект?”
А зачем? Почему нельзя вынести эту логику в отдельный метод?
Никогда не задумывался над тем, что практически любой for можно (наверное, даже лучше) заменить на объект, инкапсулирующий необходимую логику.
Зачем заменять for на объект? И как вы это сделаете?
Тот кто комфортно разрабатывает посредством ООП ни за какие пряники не вернется к фундаментальным основам языковой парадигмы, на которой это ядро строилось
Какое ядро? К каким "фундаментальным основам"? Ничего не понятно.
логическое ядро на котором построен ООП
Это какое "логическое ядро"?
ООП для того и создавался, чтоб не выносить в коллективных спорах друг другу мозги терминологией, которая по той или иной причине воспринимается субъективно
Неа, ООП не создавался для этого. И вокруг ООП до сих пор постоянно спорят о терминологии (ну вот например — что такое инкапсуляция?).
В ООП всегда представлена упрощенная интерфейсная абстракция максимально приближенная упрощенному, человеческому восприятию.
Это утверждение нуждается в доказательстве.
А какое отношение ваша картинка имеет к моим вопросам?
PS Помигать ледом 10 раз в ООП:
for _ in times(10):
led.blink()Картинка отвечает на все Ваши вопросы.
Нет.
А вот Ваш код не рабочий.
Вы, я так понимаю, никогда не слышали про псевдокод? От того, что он псевдокод, он не перестает обладать признаками ООП.
А что я Вам продемонстрировал?
Какую-то картинку.
функциональная инструкция в связке с ООП.
… я, собственно, не понимаю, где в вашей картинке ООП.
(честно признаюсь, про "функциональные инструкции" применительно к программированию я от вас первый раз услышал)
По части применения ООП в разработке фреймворков в качестве среды построения функциональных инструкций для внешнего аппаратного управлением, Вы так же не при делах.
Не, "не при делах". Я все больше по LOB-приложениям.
для понимания метода конечным юзерам важно представить абстракцию интерфейса именно в работе
Эм. Вы про программный интерфейс или про пользовательский интерфейс? Кто у вас "конечный пользователь"?
В контексте в.с.
В контексте чего?
создании абстракции пользовательского интерфейса
Я не понимаю, что такое "абстрация пользовательского интерфейса". Точнее, я могу придумать слишком много вариантов трактовки этой фразы, так что лучше объясните, что вы имеете в виду.
пользовательского интерфейса для декларативного программирования, прототайпинга и разработки конечного исполнительного кода. Пользователи [...] Должны обладать определенными знаниями в аппаратной бинарной логике, без знаний языков программирования.
Гм. Тогда при чем тут вообще ООП?
В моем случае, посредством высокоуровневого ООП
Я продолжаю не понимать, где у вас на вашей картинке "высокоуровневое ООП".
Если вы досмотрели представленный здесь видеоролик до конца, там наглядно продемонстрирована декларативная методика программирования.
Тем более не понимаю, при чем тут ООП.
В процессе разработки представленной платформы на языке G применялись функции OOП, которые являются основным элементом разработки в LabVIEW.
Гм. То есть картинка, которую вы показываете, к ООП имеет только то отношение, что где-то при разработке этого софта применялся ООП?
Тогда мои вопросы из первого коммента продолжают быть актуальны, потому что она (картинка) никак на них не отвечает.
Во всех моих публикациях Ваши минусы, самые минусатые.
Что-то мне любопытно стало, а в каких это ваших публикациях (множественное число!) вы видели мои минусы? Мне казалось, что минусы на хабре анонимны, нет?
Объекты должны представлять концепции реального мира
Это верное утверждение, но надо немного шире трактовать понятие "реальность". Это реальность не для нас, а для программы. Всё, что находится вне программы, это реальность. Внутри программы есть информационная модель этой реальности. То есть правильнее говорить не "реального мира", а "внешнего мира". Модель в программу закладывает программист. Он строит модель при анализе предметной области.
Предметная область это необязательно физические объекты, это может быть например сценарий игры. Для программы это все равно внешняя по отношению к ней сущность. Чтобы программа вела себя в соответствии с задуманным авторами игры сценарием, программист должен заложить в нее соответствующую информационную модель этого сценария.
Правильная модель это такая, которая максимально точно моделирует поведение моделируемой сущности и составляющих ее элементов. Поэтому да, объекты в программе должны представлять концепции внешнего для программы мира.
Это не в программе есть какие-то дополнительные объекты, а в предметной области есть объекты, которые мы не замечаем. Оператор, который заполняет заявку по данным клиента, действует по инструкции заполнения этих заявок, которую ему сообщили при обучении. Эту же инструкцию сообщили другим операторам. В данном случае оператор это просто процессор, выполняющий инструкцию и запоминающий какие-то временные значения. Поэтому вынесение этой логики в отдельный объект с состоянием и поведением это правильная модель этого процесса.
Отдельные элементы программы это тоже информационные системы, и к ним можно применить тот же принцип. Сущности "Схема базы данных" нет в предметной области, но она есть в другой информационной системе "база данных", с которой взаимодействует наша программа.
Из этого идет и разделение программы на слои. В слое бизнес-логики содержится модель предметной области, в других слоях соответствующие им модели внешних систем или правил. Например, понятие "DI-контейнер" не относится к бизнес-логике, это модель договоренности "Давайте у нас будет специальный инструмент, который будет пробрасывать зависимости в объекты в соответствии с нашими настройками".
Что такое объект