xam1816
У объекта есть границы, отделяющее его внутреннее состояние от всего другого, что не является этим же объектом. Соответственно объект занимает какое-то пространство.

У объекта есть поведение - способность изменять свое состояние. Под состоянием подразумевается его характеристики, свойства, данные

Объект сообщается с внешним миром. Он получает сообщения, реагирует, отправляет сообщения.

Вот с этого момента и начались все мои приключения.

Как я понимаю объект:

Объект: Телевизор(42 дюйма, 10кг, черный, выключен)

Свойства:

размер диагонали (число),
вес (число),
цвет (строка),
состояние (включен, выключен - логический),
кнопка вкл/выкл (объект типа Кнопка),
кнопка громкости (тише, громче, объект типа Кнопка)

Функции:

1. Включить,
2. Выключить
3. Переключить канал вперед
4. Переключить канал назад
5. Повысить громкость
6. Понизить громкость

Объект: Менеджер_Работы_С_Записями_Базы_Данных(…)

Свойства:

данные для формирования записи (словарь)
айди записи (число)
фильтр для получения разного набора записей (строка, число, дата и тд)

Функции:

1. Создать запись на основе “данные для формирования записи”
2. Получить запись на основе “айди записи”
3. Обновить данные записи на основе “айди записи” и “данные для формирования записи”
4. Получить набор записей на основе “фильтр для получения разного набора записей”
3. Удалить запись на основе “айди записи”

xam1816
Скажите, какие объекты вы можете выделить в вашей программе?

Я выделяю следующие объекты:
1. Объекты моделей sqlalchemy - описывают таблицу БД как объект, состоящий из полей таблицы с описанием ограничений и значений по умолчанию, связей и внешних ключей.
2. Объект - хранилища библиотеки pydantic, которые используются для валидации данных. В моем случае не имеют собственных методов, только встроенные.
Эти объекты, по сути, хранят необходимый для работы набор полей из объектов моделей sqlalchemy. Служат для создания нужной кей-велью структуры для сохранения в БД.
3. Объекты - менеджеры, как в описанном “Менеджер_Работы_С_Записями_Базы_Данных”. Являются менеджером, который получает те или иные данные в свое состояние и производит работу с БД, на основе этих данных. Каждый менеджер отвечает за раздел данных, например менеджер работы с разделом “Серверы” или разделом “Договоры с интернет провайдером”. Некоторые являются менеджером работы со связанными по смыслу менеджерами. Например менеджер, который составляет список доступов к серверу, на основе указанных в разделе “Договоры с интернет провайдером” IP адресов.
4. Объект - сессия работы с базой данных. Является частью sqlalchemy
5. Объекты - отчеты. Формируют отечты в разных форматах, на основе переданных в них данных из БД.

Примерно так.

bootcd
Как я понимаю объект:

Объект: Телевизор(42 дюйма, 10кг, черный, выключен)

Свойства:

размер диагонали (число),
вес (число),
цвет (строка),
состояние (включен, выключен - логический),
кнопка вкл/выкл (объект типа Кнопка),
кнопка громкости (тише, громче, объект типа Кнопка)

Функции:

1. Включить,
2. Выключить
3. Переключить канал вперед
4. Переключить канал назад
5. Повысить громкость
6. Понизить громкость

Где хранится канал? Где хранится громкость?
Если кнопку громкости извлечь из телевизора, у него не будет звука?

py.user.next
Где хранится канал? Где хранится громкость?
Если кнопку громкости извлечь из телевизора, у него не будет звука?

Это, весьма, общий пример. Но ваше замечание справедливо.

Добавим свойства:

текущая громкость (число)
текущий канал (число)
динамики (объект типа Динамик)
текущие настройки (кей-велью структура)

Добавить методы:
сохранение текущих настроек перед выключением

Правильно ли я понимаю, что декомпозиция зависит от бизнес логики?
То есть Телевизор как объект, например в магазине электроники - это про размер, вес, цвет, бренд и прочее. телевизор на фабрике телевизоров - это про кнопки, матрицу, корпус и тд.

bootcd
Правильно ли я понимаю, что декомпозиция зависит от бизнес логики?

От поставленной задачи это зависит. Например, если телевизор надо в окно выкинуть, там нужен только вес, размер. Если телевизор продаётся, то его, может быть, надо включить, но хранить настройки в нём, переключать параметры - это всё не надо. Если телевизор используется для просмотра передач в каком-то помещении, то нужно иметь в нём громкость. То есть телевизор там, телевизор там и телевизор там - это всё разные телевизоры, хоть это может быть и один и тот же реальный телевизор. Это абсолютно разные объекты. Объект - это не сам телевизор, объект - это его модель (математическая). А модель - это обеднённое описание чего-то из реального мира. Поэтому и нельзя сразу сказать “телевизор будет иметь молекулы”. Молекулы, конечно, есть в телевизоре реальном, только вот для задачи они совсем не нужны. Так-то там бесконечно можно всё добывать через разложение. Неизвестно, где мир реальный заканчивается.

Факт в том, что есть у него операции в данном случае. Операция переключения канала. То есть телевизор может показывать первый канал, а может показывать второй канал. Какая разница между телевизором, показывающим эти два разных канала? Ну он что-то разное делает, какие-то разные проявления у него. А почему у него разные проявления происходят? Потому что он в разных состояниях. Это два разных состояния телевизора “показывает первый канал”, “показывает второй канал”. При добавлении звука там ещё состояния обнаруживаются - “звучит тихо”, “звучит громко”. А различается ли телевизор этот, когда он звучит тихо на первом канале и звучит громко на втором канале? А различается ли телевизор этот, когда он звучит громко на первом канале и звучит тихо на втором канале? А различается ли телевизор этот, когда он звучит тихо на первом канале и звучит тихо на втором канале? Да, различается. Получается, что у него уже есть четыре разных состояния. У этого объекта четыре разных состояния. А состояние объекта - это кортеж значений всех его свойств. Поэтому нужно в каком-то свойстве хранить его канал. Поэтому нужно в каком-то свойстве хранить его громкость.

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


tags: oop object state

> По крайней мере сджойнить что-то с фильтрами, сортировками и подзапросами смогу.

Это уже неплохо. Процентов 90 чебурашек на это не способны.

> Вот с этого момента и начались все мои приключения.

Для начала тебе нужно понять что объект состоит из двух частей:
1) Интерфейс - механизма взаимодействия с другими объектами
2) Реализация - внутреннее устройство объекта взаимодействие с которым происходит только через интерфейс
В этом и состоит вся суть абстракции при помощи объектов.

> Вот я как раз не могу уловить эти моменты. … я использую сессии, которые насколько я понимаю, как раз и призваны обеспечивать транзакции в БД.

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

> Соответственно тот, кто пишет книги про то, как писать программы, сам не особо этим занят, раз есть время возиться с книгами.

Всё ещё хуже. Тот кто пишет книги очень часто сидит на грантах. А что бы грант получить книга должна быть “очень умной” по этому их намеренно переусложняют.

С точки зрения ООП База Данных - это объект. Этот объект имеет четкие границы, внутри него есть данные, которыми только он (объект) распоряжается, он может принимать сообщения в виде запросов, реагировать на них и отправлять сообщения обратно. Этот объект может существовать сам по себе.

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

сообщение => “черный ящик” => сообщение. Что в черном ящике никого еб…ть не должно, это его дело. Но мы точно знаем что у него есть какая-то функциональность, и чтобы ей воспользоваться нужно отправить ему сообщение, которое он понимает и реагирует на него.

Интернет построен по принципу ООП.

Удаленный сервер - объект. Как там в нем все устроено никому не интересно. Мы просто отправляем ему сообщение, он дает нам ответ обратно с полезными данными или бесполезными. Сервер существует сам по себе, браузер может жить сам по себе.

Так вот когда ты пишешь ключевое слово class, ты говоришь интерпретатору, что собираешься выделить пространство для объекта, там внутри будешь творить все что хочешь, это уже будет дело объекта, единственное, чтобы он мог сообщаться с внешним миром, он должен уметь принимать сообщения и возвращать их обратно. Этот объект может существовать сам по себе.

Наделаешь таких объектов, и налаживаешь между ними взаимодействие, кто за что отвечает, подобно в организации из людей.

xam1816
С точки зрения ООП База Данных - это объект. Этот объект имеет четкие границы, внутри него есть данные, которыми только он (объект) распоряжается, он может принимать сообщения в виде запросов, реагировать на них и отправлять сообщения обратно. Этот объект может существовать сам по себе.Пример из реальности - машинка на радио управлении. У нее как объекта есть границы, у нее есть состояние, она может менять свое состояние - двигаться, поворачивать колеса, включать сирену, она принимает сообщения в виде радио сигналов, реагирует, возвращает сообщение обратно, в реальности сообщение не обязательно слова какие-то, а вообще сам факт того что ты видишь, что машина переместилась в пространстве и извлекла звуки которые передались по воздуху - это все сообщение.сообщение => “черный ящик” => сообщение. Что в черном ящике никого еб…ть не должно, это его дело. Но мы точно знаем что у него есть какая-то функциональность, и чтобы ей воспользоваться нужно отправить ему сообщение, которое он понимает и реагирует на него.Интернет построен по принципу ООП.Удаленный сервер - объект. Как там в нем все устроено никому не интересно. Мы просто отправляем ему сообщение, он дает нам ответ обратно с полезными данными или бесполезными. Сервер существует сам по себе, браузер может жить сам по себе.Так вот когда ты пишешь ключевое слово class, ты говоришь интерпретатору, что собираешься выделить пространство для объекта, там внутри будешь творить все что хочешь, это уже будет дело объекта, единственное, чтобы он мог сообщаться с внешним миром, он должен уметь принимать сообщения и возвращать их обратно. Этот объект может существовать сам по себе.Наделаешь таких объектов, и налаживаешь между ними взаимодействие, кто за что отвечает, подобно в организации из людей.

Концепция черного ящика мне понятна.
Как раз я и пытаюсь создать некоего менеджера, обслуживающего работы с БД в контексте какого-то смыслового раздела в виде этого черного ящика.
Такое иногда именуют как “паттерн Репозиторий” или CRUD Service.
То есть менеджер - это по сути набор функций, который работает с данными, которые ему передали.
Например. Пришли данные из формы. Менеджер, на тебе эти данные, валидируй и сохрани их в БД в виде записей. Менеджер, получи из БД запись по такому то фильтру. Менеджер, удали такую-то запись вот по такому айди. И так далее.
Вопросы у меня появились тогда, когда я не смог понять, что есть объект этого менеджера. Что есть его состояние.
Я видел, на самом деле, реализации таких менеджеров. Я упомянул это и мне сразу насыпали про горе-учителей, горе-писателей книг и все такое.
Мне понятный объекты, когда я их порождаю, задавая начальное состояние. То есть когда объект инициализируется ему могут задать вот такое и вот такое начальное свойство. И для всех объектов этого типа будет всегда задаваться такое вот начальное состояние. Оно будет разное по значению, но одинаковое по наполнению. С менеджером же работы с записями в БД, я с наскока не разобрался. реализовал набор методов в классе просто ради неймспейса (мог сделать просто на уровне модуля) так как мне необходимо было запустить продукт в работу. Но из-за присущей мне тяги к правде и непринятия махровых новаторств, я решил разобраться, заодно прокачать себя в этом направлении, что меня привело вот сюда.

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

bootcd
Например. Пришли данные из формы.

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

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

Объект создаётся и начинает жить. Жизнь объекта включает его состояния и его поведения. Потом объект умирает. От жизни до смерти он может побывать в одном состоянии, а может побывать в пяти состояниях, возвращаться из одних состояний в другие или переходить всё время в новые состояния безвозвратно. Состояние объекта хранится в его свойствах.

Классов тут нет, это только объекты. Классы делать ещё сложнее, чем объекты. Но и без классов на одних объектах можно сделать много чего.