Что такое Обьект в программировании?

@CoderHuligan · Регистрация: 30.06.2015

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

Меня серьёзно интересует понятие обьекта в программировании. Мы действительно живём в окружении различных обьектов, так и привыкли мыслить. Да, действительно это естественно так думать: вот один обьект допустим Вася, а вот второй Ваня, и Вася у Вани просит прикурить. Но, так бывает, что у Вани кончились спички, к великому сожалению Васи, а может и к счастью..
Ваня и Вася действительно обьекты, ибо имеют абстрактное имя, которое их определяет и отличает их от других обьектов. Также они имеют свою индивидуальность в виде разных свойств: у одного нос крючком, а у другого нос горбом, в общем понятно.. К тому же они имеют состояние, так как между отключками на сон не забывают кто они такие, и что делали вчера(хотя некоторые индивиды это забывают..), и что намерены сделать сегодня.
Понятие обьекта довольно размыто в программировании, а казалось бы должно быть всё наоборот: информатика должна быть точной наукой, которая основана на математических концепциях. Но этого нет, и каждый понимает понятие "обьект" по своему. Так это или не так? Я думаю так.
Так как же вы, со своей стороны, понимаете это кардинальное понятие?.
Как я считаю?
А я считаю, что не нужно переносить биологические(физиологические) особенности на область программинга. Обьект, на мой взгляд, не может иметь наследников, как не может и сам быть наследником, ибо тогда он будет несамостоятельной сущностью. Он будет от своего рождения привязан пуповиной к кому-то ещё. Его нельзя будет выдернуть из этой "семьи" (опять биология) и применить где-либо ещё. Даже с точки зрения биологии (против чего я выступаю).
Также я считаю, что не гоже помещать функции, которые обеспечивают функционал данного обьекта в сам этот обьект. Если в реальной жизни живое существо действует как бы самостоятельно, то это только так кажется ибо существа одного типа действуют в общем то типичными образами, поведенческие реакции которых можно разложить на немногочисленные составляющие, чем и занимается такая наука, как психология.
Короче говоря постоянно прослеживается нечто общее в поведении многих обьектов, и этого отрицать не имеет смысла ибо это очевидный факт.
Если в одном и том же обьекте собран весь его функциональный багаж, то как его, к примеру, сохранить на диск или переслать по сети, при этом сохраняя его состояние, если таковое есть(а Гради Буч писал, что обьект имеет состояние!), наиболее естественным образом? Естественным - никак, не так ли? Может быть противоестественным?..
Далее, ещё вопросы.
Последуем логике классиков ООП и определим что же такое состояние.
В Си есть такая функция - strtok(), так вот она имеет статическую переменную, которая сохраняет своё значение между вызовами этой функции. А так как эта переменная кроме как из этой функции не видна, то можно считать данную функцию имеющей своё состояние(она эту переменную инкапсулирует). Другие функции такого состояния не имеют действуя по принципу загрузил параметр/ы - возвратил значение/я. То есть между вызовами этих функций состояние не сохраняется.
А обьект, по мысли классиков, должен сохранять. То бишь обьект не является обьектом если такового не имеет..
Вопрос: как у вас с этим делом? Сохраняет ли у вас обьект своё состояние между началом своей жизни и её концом?
Является ли ваш обьект самостоятельной сущностью во всех смыслах? Можно ли его переслать по сети или загрузить на диск или с диска? Может быть вы как это обычно и бывает создаёте свои классы, как хранилища процедур и данных, безотносительно к тому есть ли какое-либо состояние у этого обьекта или нет, тем самым имитируя простую модульность, которая была ещё в древнем Паскале с Модулой? Имеете ли вы право называть обьектом сие творение? Вам вообще не стыдно?..
Является ли ваш обьект живым существом, самостоятельной сущностью, а не завязан многочисленными связями по всему коду? Знают ли другие сущности системы его внутренне устройство?.

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

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

В ООП поведение обьекта определяется его методами(как бы), однако это всего лишь функции, которые этот обьект выполняет, а кто направляет и контролирует его поведение совершенно не ясно. Я знаю, что в этом случае придумали некие "паттерны" проектирования, которые есть нечто иное, как ветвистые костыли, чтобы хоть как-то обеспечить функционал системы в целом.
Я не могу проверить в каком состоянии находится обьект в ООП. В ООП обьект рефлекторно реагирует на внешние раздражители, а раздражают его другие обьекты. Он не самостоятелен и не может жить без других. Это поведение глупой амёбы.. А наш может.. Поэтому наш более "обьектен"..
Короче говоря, я считаю обьектом некий статический агрегат, в котором имеется поле состояния. Этот агрегат абстрактное существо, живое существо, благодаря инфо о состоянии. В одном модуле можно собрать весь функционал системы, который отвечает за жизнь нашего питомца, но это не определяющее требование, а всего лишь возможность.
Это не физиологический обьект, а чисто компьютерный, ибо живёт в компьютере, а не в головах теоретиков.
А что вы считаете обьектом?

@korvin_ · 11.12.2018, 11:59

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

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

Не так. Правильно: из-за пиара ООП мы начали мыслить, что живём в окружении «объектов».

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

вот один объект, допустим Вася, а вот второй — Ваня, и Вася у Вани просит прикурить.

В реальном мире в этой ситуации мы называем Васю субъектом.

A Theory of Objects

@CoderHuligan · 11.12.2018, 12:34 **[ТС]**

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

В реальном мире в этой ситуации мы называем Васю субъектом.

Хорошая книжка.
Скорее всего понятие обьект возникло по аналогии с обьектом управления. Просто на него начали возлагать обязанности, которые присущи только субьектам. Это из терминологии кибернетики и теории управления https://ru.wikipedia.org/wiki/Объект_управления
То есть произошла подмена понятий.
"Обьект управления технической системы не выполняет функций принятия решений, то есть не формирует и не выбирает альтернативы своего поведения, а только реагирует на внешние (управляющие и возмущающие) воздействия, изменяя свои состояния предопределенным его конструкцией образом." (оттуда).
Это математически правильное определение обьекта управления.
Простой агрегат с полем состояния и есть такой обьект управления. Он сам не принимает никаких решений, а просто сохраняет свои свойства и сохраняет состояние. Им управляют, а не он управляет, как субьект.

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

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

Не так.

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

@CoderHuligan · 13.12.2018, 17:05 **[ТС]**

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

Скорее всего понятие обьект возникло по аналогии с обьектом управления.

Нет, скорее всего, эти люди просто либо не знали что существуют такие науки как Теория Управления и Кибернетика, либо делали это сознательно. Частным случаем последней является "изучение обратной связи, чёрных ящиков и производных концептов, таких как управление и коммуникация в живых организмах, машинах и организациях, включая самоорганизации. "(из вики).
https://ru.wikipedia.org/wiki/Кибернетика
Похоже на то, что эти науки вообще не учитывались при создании новой обьектной системы. Ведь совершенно очевидно что обьект управления не может являться самоуправляемой сущностью. Например имеем обьект управления "вентиль". Предположим, что он неизменен сам по себе. Этим вентилем может управлять не только какая-то то одна управляющая сущность, а множество таковых. Приведу пример. Создали мы обьект "вентиль" и запихнули туда определённый функционал(внутрь обьекта). Приходит управляющая сущность (УС), которая заточена именно на конкретный функционал вентиля (уже здесь стоит насторожится, ибо УС знает о внутреннем функционале), и начинает им управлять подавая команды: "открыть задвижку", "закрыть задвижку" и т.п. Со временем нам понадобился другой более расширенный функционал вентиля, к примеру, "открыть задвижку за 30 секунд", "закрыть задвижку на половину", "перейти в режим ожидания и ожидать 45 секунд" и т.п. В этом случае нам придётся вносить изменения во всю систему, что противоречит принципу открытости: "Программные сущности должны быть открыты для расширения, но закрыты для изменений."
Что же произошло? УС часть своей ответственности переложила на обьект управления (ОУ). Она делегировала то, чем должна обладать сама самому этому ОУ жёстко заложив в нём конкретный функционал, который, по мысли этого УС должен выполнять обьект. Но тут появляется другая УС - УС-2 и говорит, что ей нужен другой, несколько отличный функционал, а место-то занято уже первым УС..
К чему я веду, а к тому, что обьект управления должен оставаться обьектом управления, и ничем больше. В таком случае управлять им могут множество разных УС, и это полностью будет соответствовать open/close принципу. ОУ закрыта для изменений, а ОУ открыта. При этом мы вводим не одно понятие обьекта, а два понятия:
1. Обьект управления.
2. Устройство управления.

Добавлено через 2 часа 45 минут
Добавлю, что есть такая наука - Теория автоматического управления (ТАУ), которая изучает эти вопросы сточки зрения математики: https://ru.wikipedia.org/wiki/... управления.
Так вот, по этой теории, упрощённо можно разделить систему не на две составляющих, а на три(основных) это:
1. Обьект управления.
2. Устройство управления.
3. Регулятор.
которые примерно располагаются в такой последовательности: Устройство управления > Регулятор > Обьект управления. Они могут быть связаны так называемыми обратными связями, например тот же регулятор и обьект.
Но это слишком абстрактные понятия. Приведу пример.
В реактивных системах, которые управляются конкретными пользователями(вне программы), устройством управления является сам этот человек-пользователь программы. В программе же остаются только ОУ и регуляторы.
А в автоматических системах, которые управляются автоматически без участия человека, автоматическая система управления (АСУ) является целостной средой выполнения и включает в себя все эти три составляющие.
Например в веб-приложениях CMS, форумных движках, применяется реактивные системы, которые реагируют на запросы пользователей, то бишь сами пользователи являются управляющими устройствами (УУ). Они не долгоживущие системы.
Долгоживущие АСУ имеют место быть например в технологических процессах, в тех же игровых движках, которые управляют обьектами игрового мира продолжительное время.
Математический аппарат, который описывает построение таких АСУ подробно разработан, и является надёжной базой для возможного построения непротиворечивых АСУ на существующих языках, или создания отдельного специального языка для описания систем управления. К сожалению такого языка ещё не создано. Однако это позволило бы привнести в область программирования достаточно разработанные научные методы.

@Грегори_ · 24.12.2018, 14:33

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

В реальном мире в этой ситуации мы называем Васю субъектом.
Хорошая книжка.
Скорее всего понятие обьект возникло по аналогии с обьектом управления. Просто на него начали возлагать обязанности, которые присущи только субьектам. Это из терминологии кибернетики и теории управления https://ru.wikipedia.org/wiki/Объект_управления
То есть произошла подмена понятий.
"Обьект управления технической системы не выполняет функций принятия решений, то есть не формирует и не выбирает альтернативы своего поведения, а только реагирует на внешние (управляющие и возмущающие) воздействия, изменяя свои состояния предопределенным его конструкцией образом." (оттуда).

А разве объект может? он ведь действует согласно предопределённым его конструкцией образом. Кто объект, а кто субъект- это тонкая философская тема. Если мы верим в спонтанность, свободу воли и существование выбора- человек это субъект. Если нет- то он действует по хитрым законам психики (которые мы пока не в состоянии понять полностью). А животные не слишком развитые живущие согласно инстинкту? Птицы? рыбы? Тараканы?
===
для меня это скорее удобный методический элемент для разложение мира на части при создании моделей. Можно отталкиваться от процессов. Можно- от объектов. Вопрос модели мышления. И её воплощения в программной системе.

@CoderHuligan · 24.12.2018, 16:38 **[ТС]**

Сообщение от Грегори_

Если мы верим в спонтанность, свободу воли и существование выбора- человек это субъект.

Для меня человек, как и любое живое существо есть сложный набор статических данных, обьект управления. Устройство управления человека это его душа, что выражается его мыслительной деятельностью. Душа тоже управляется некой матрицей общих архетипов поведений. Над всем же стоит дух - Супер управляющий. Это сам человек в силу своей необразованности может считать себя субьектом, но это не так.
Поэтому нужно разделять систему на две независимые сущности: 1. обьект управления и 2. управляющего субьекта.
Обьект это статика. Субьект динамика.
Человек находится в состоянии сна. Тело бездействует, а душа продолжает функционировать, и думать что не спит. Это говорит, что тело в целом, как форма это статическая система.

Сообщение от Грегори_

А животные не слишком развитые живущие согласно инстинкту? Птицы? рыбы? Тараканы?

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

Сообщение от Грегори_

Можно отталкиваться от процессов. Можно- от объектов.

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

@Грегори_ · 24.12.2018, 16:51

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

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

Это ваши личные религиозные верования. С учётом того что они приводятся голословно- можно с тем же успехом утверждать что над всем стоит прародитель- крокодил. И кстати носители таких верований не меньше вашего убеждены в своей правоте. К объектам это естественно отношения не имеет

@CoderHuligan · 24.12.2018, 17:04 **[ТС]**

Сообщение от Грегори_

С учётом того что они приводятся голословно

Они приводятся на основании моего собственного опыта. Поэтому они научны (для меня лично). Это моя наука. Она мне помогает в программировании. Ваша личная наука вам по всей видимости тоже помогает, но с другой стороны. Если вам легче мыслить в ООП стиле мыслите именно так. Я лично так мыслить не могу.

Добавлено через 5 минут
Вслед за индийскими философами я делю мир на Акашу и Прану, то есть на Вещество и Энергию.

@Pokomit_T · 02.03.2023, 19:44

где вы читали что прародитель - крокодил?

@eva2326 · 04.03.2023, 20:36

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

В реальном мире в этой ситуации мы называем Васю субъектом.

Объектом.

Субъектом Вася является для самого себя, а для внешних наблюдателей он - объект.

Субъект (от лат. subjectum «подлежащее»): Субъект в грамматике — подлежащее, семантическая категория со значением производителя действия или носителя состояния.

Объект — философская категория, выражающая нечто, на что направлена практическая или познавательная деятельность субъекта (наблюдателя).

@Ludwig Valentin · 08.03.2023, 04:29

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

@eva2326 · 08.03.2023, 09:27

Сообщение от Ludwig Valentin

Естественно, объектно-ориентированный подход требует большей мощности процессора и параллельных вычислений

Это бред.

Раз вы такое написали, то вероятно вы думаете, что под капотом объектно ориентированных языков какая то магия ?))
И вот эта магия, что бы поддерживать ооп требует каких то дополнительных ресурсов?

Чушь!

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

Например, первые компиляторы с++ по началу транслировали код на язык си.
Тобишь, убирали всю эту оппнутую мишуру, обнажая его процедурную суть.
И только спустя какое то время, начали транслировать сразу в машкоды.

Как видит код программист, у которого ооп-головного мозга:

C++

1
2
3

Собаки собачка;     // Создание объекта ООП
 
собачка.гавкай();   // Запуск метода

А как видит код компилятор:

C++

struct Собаки собачка;  // Создание объекта сишной структуры
 
гавкай(собачка);        // Запуск обычной функции си, 
                        // которой аргументом передали объект,
                        // над которым нужно совершить действие

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

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

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

@Ludwig Valentin · 08.03.2023, 09:29

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

Это бред.
Раз вы такое написали, то вероятно вы думаете, что под капотом объектно ориентированных языков какая то магия ?))
И вот эта магия, что бы поддерживать ооп требует каких то дополнительных ресурсов?
Чушь!
Поддержка оо-программирования в оо-языках - это всего лишь синтаксический сахар, реализуемый поверх обычной процедурной парадигмы.
Например, первые компиляторы с++ по началу транслировали код на язык си.
Тобишь, убирали всю эту оппнутую мишуру, обнажая его процедурную суть.
И только спустя какое то время, начали транслировать сразу в машкоды.

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

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

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

прогресс - от сатаны говорите?
а вы фильтруйте технологию, оставляйте хорошее и полезное
или я получаюсь прагматиком?
если вы про коллегу, то подписываю коллегу
у меня университетский диплом.
а англичане так и говорят колледж.
если вы против прогресса, давайте перейдём на ламповый ЭНИАК.
он вполне справлялся с расчётом артиллерийских таблиц

@escoult · 08.03.2023, 13:51

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

И вот эта магия, что бы поддерживать ооп требует каких то дополнительных ресурсов?
Чушь!

Как-то в 2018 мы в ветке С# решали олимпийскую задачку ("Коррупция"). Проблема была влезть в лимит времени (100 мс, 64 MiB). Решалась написанием своих методов Parse, Split и сортировки. Таким образом удавалось втиснуться в 100 мс, результаты были 83 мс, 92 мс, около того, и примерно 30 MiB памяти. В этом году она мне вспомнилась, и я решил переписать ее на С. Используя тот же алгоритм, результаты 2 мс и 500 кб памяти. Потом подумал, а можно ли еще меньше. Повозился с алгоритмом, снизил до 176 кб. Разница с "магией" в разы.

@eva2326 · 08.03.2023, 14:54

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

Разница с "магией" в разы.

Нелогичным людям свойственно путать С# с "магией".

@escoult · 08.03.2023, 15:27

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

Нелогичным людям свойственно путать С# с "магией".

Слава Б-гу, что хоть не начали "просвящять" меня и рассказывать что такое .NET и как он работает. ))

@vantfiles · 08.03.2023, 16:12

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

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

Пфффф...

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

Lua

a = 123
print( a )
a = "сто двадцать три"
print( a )

Вариант на Си?

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

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

статическую типизацию

я об этом.

@korvin_ · 08.03.2023, 20:24

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

Lua

a = 123
print( a )
a = "сто двадцать три"
print( a )

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

> статическую типизацию
я об этом.

Это не интересно

Go

package main
 
import "fmt"
 
func main() {
    var a any
    a = 123
    fmt.Println(a)
    a = "сто двадцать три"
    fmt.Println(a)
}

— https://go.dev/play/p/xKnFqADNFjd

Haskell

main = do
    let a = 123
    print a
    let a = "one hundred and twenty three"
    print a

— http://tpcg.io/_MC32MD

@Ludwig Valentin · 08.03.2023, 21:09

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

Нелогичным людям свойственно путать С# с "магией".

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

@Ludwig Valentin · 08.03.2023, 21:20

довожу до вашего сведения
пример блок-схемы

@CoderHuligan 1287 / 880 / 254 Регистрация: 30.06.2015 Сообщений: 4,593 Записей в блоге: 51
		1
	Что такое Обьект в программировании? 11.12.2018, 11:05. Показов 5626. Ответов 64 Метки ООП (Все метки) Меня серьёзно интересует понятие обьекта в программировании. Мы действительно живём в окружении различных обьектов, так и привыкли мыслить. Да, действительно это естественно так думать: вот один обьект допустим Вася, а вот второй Ваня, и Вася у Вани просит прикурить. Но, так бывает, что у Вани кончились спички, к великому сожалению Васи, а может и к счастью.. Ваня и Вася действительно обьекты, ибо имеют абстрактное имя, которое их определяет и отличает их от других обьектов. Также они имеют свою индивидуальность в виде разных свойств: у одного нос крючком, а у другого нос горбом, в общем понятно.. К тому же они имеют состояние, так как между отключками на сон не забывают кто они такие, и что делали вчера(хотя некоторые индивиды это забывают..), и что намерены сделать сегодня. Понятие обьекта довольно размыто в программировании, а казалось бы должно быть всё наоборот: информатика должна быть точной наукой, которая основана на математических концепциях. Но этого нет, и каждый понимает понятие "обьект" по своему. Так это или не так? Я думаю так. Так как же вы, со своей стороны, понимаете это кардинальное понятие?. Как я считаю? А я считаю, что не нужно переносить биологические(физиологические) особенности на область программинга. Обьект, на мой взгляд, не может иметь наследников, как не может и сам быть наследником, ибо тогда он будет несамостоятельной сущностью. Он будет от своего рождения привязан пуповиной к кому-то ещё. Его нельзя будет выдернуть из этой "семьи" (опять биология) и применить где-либо ещё. Даже с точки зрения биологии (против чего я выступаю). Также я считаю, что не гоже помещать функции, которые обеспечивают функционал данного обьекта в сам этот обьект. Если в реальной жизни живое существо действует как бы самостоятельно, то это только так кажется ибо существа одного типа действуют в общем то типичными образами, поведенческие реакции которых можно разложить на немногочисленные составляющие, чем и занимается такая наука, как психология. Короче говоря постоянно прослеживается нечто общее в поведении многих обьектов, и этого отрицать не имеет смысла ибо это очевидный факт. Если в одном и том же обьекте собран весь его функциональный багаж, то как его, к примеру, сохранить на диск или переслать по сети, при этом сохраняя его состояние, если таковое есть(а Гради Буч писал, что обьект имеет состояние!), наиболее естественным образом? Естественным - никак, не так ли? Может быть противоестественным?.. Далее, ещё вопросы. Последуем логике классиков ООП и определим что же такое состояние. В Си есть такая функция - strtok(), так вот она имеет статическую переменную, которая сохраняет своё значение между вызовами этой функции. А так как эта переменная кроме как из этой функции не видна, то можно считать данную функцию имеющей своё состояние(она эту переменную инкапсулирует). Другие функции такого состояния не имеют действуя по принципу загрузил параметр/ы - возвратил значение/я. То есть между вызовами этих функций состояние не сохраняется. А обьект, по мысли классиков, должен сохранять. То бишь обьект не является обьектом если такового не имеет.. Вопрос: как у вас с этим делом? Сохраняет ли у вас обьект своё состояние между началом своей жизни и её концом? Является ли ваш обьект самостоятельной сущностью во всех смыслах? Можно ли его переслать по сети или загрузить на диск или с диска? Может быть вы как это обычно и бывает создаёте свои классы, как хранилища процедур и данных, безотносительно к тому есть ли какое-либо состояние у этого обьекта или нет, тем самым имитируя простую модульность, которая была ещё в древнем Паскале с Модулой? Имеете ли вы право называть обьектом сие творение? Вам вообще не стыдно?.. Является ли ваш обьект живым существом, самостоятельной сущностью, а не завязан многочисленными связями по всему коду? Знают ли другие сущности системы его внутренне устройство?. Если обьект должен сохранять информацию о том, в каком состоянии он находится в данный момент времени, то он есть живое существо, некий долгоиграющий механизм, автомат, робот, который производит некие действия во времени. Не одно действие, а обеспечивает работу некоего процесса. Приведу пример(извините за длинный пост, но он того стоит, поверьте..). Назовём агрегатом структуру из полей разных типов. Имеем например обьект "Робот". Агрегат состоит из полей, которые определяют его свойства, например - цвет робота, материал, количество конечностей и т.п.. Это ещё не обьект, ибо имеет только статические свойства. Но, чтобы он стал полноценным обьектом, мы в него добавляем дополнительное поле: состояние. Оно описывает поведение данного обьекта в каждый момент времени. Просто прочитав эту переменную мы можем узнать в каком состоянии находится робот в данный момент. Оно не размыто по разным "флагам", как обычно, по всему коду, а собрано в одной единственной переменной. Состояния - "движение вверх", "движение вниз", "стоит на месте", "поворачивает на право", "берёт клешнями предмет" и т.д.(их может быть много), определяют его абстрактное поведение. Функция-автомат принимает этот агрегат-обьект и переходит в то состояние, в котором находится обьект(читает это поле). По завершении работы она переходит в начальное сохраняя себя в виде чёрного ящика и не имея своего состояния (мечта функциональщиков). В этой функции мы держим всю логику этого обьекта и вызываем соответствующие функции, которые определяют конкретные действия обьекта. Такой обьект можно передать по сети, можно загрузить на диск и обратно. Причём обьект будет сохранять своё состояние. Например обьект компьютерной игры нужно сохранить так, чтобы при следующем включении игра началась с того самого места, в котором была прервана.. В ООП поведение обьекта определяется его методами(как бы), однако это всего лишь функции, которые этот обьект выполняет, а кто направляет и контролирует его поведение совершенно не ясно. Я знаю, что в этом случае придумали некие "паттерны" проектирования, которые есть нечто иное, как ветвистые костыли, чтобы хоть как-то обеспечить функционал системы в целом. Я не могу проверить в каком состоянии находится обьект в ООП. В ООП обьект рефлекторно реагирует на внешние раздражители, а раздражают его другие обьекты. Он не самостоятелен и не может жить без других. Это поведение глупой амёбы.. А наш может.. Поэтому наш более "обьектен".. Короче говоря, я считаю обьектом некий статический агрегат, в котором имеется поле состояния. Этот агрегат абстрактное существо, живое существо, благодаря инфо о состоянии. В одном модуле можно собрать весь функционал системы, который отвечает за жизнь нашего питомца, но это не определяющее требование, а всего лишь возможность. Это не физиологический обьект, а чисто компьютерный, ибо живёт в компьютере, а не в головах теоретиков. А что вы считаете обьектом? 1

@korvin_ 4486 / 2721 / 485 Регистрация: 28.04.2012 Сообщений: 8,590
	11.12.2018, 11:59	2
	Сообщение от CoderHuligan Мы действительно живём в окружении различных объектов, так и привыкли мыслить. Не так. Правильно: из-за пиара ООП мы начали мыслить, что живём в окружении «объектов». Сообщение от CoderHuligan вот один объект, допустим Вася, а вот второй — Ваня, и Вася у Вани просит прикурить. В реальном мире в этой ситуации мы называем Васю субъектом. A Theory of Objects Миниатюры 0

@CoderHuligan 1287 / 880 / 254 Регистрация: 30.06.2015 Сообщений: 4,593 Записей в блоге: 51
	11.12.2018, 12:34 [ТС]	3
	Сообщение от korvin_ В реальном мире в этой ситуации мы называем Васю субъектом. Хорошая книжка. Скорее всего понятие обьект возникло по аналогии с обьектом управления. Просто на него начали возлагать обязанности, которые присущи только субьектам. Это из терминологии кибернетики и теории управления https://ru.wikipedia.org/wiki/Объект_управления То есть произошла подмена понятий. "Обьект управления технической системы не выполняет функций принятия решений, то есть не формирует и не выбирает альтернативы своего поведения, а только реагирует на внешние (управляющие и возмущающие) воздействия, изменяя свои состояния предопределенным его конструкцией образом." (оттуда). Это математически правильное определение обьекта управления. Простой агрегат с полем состояния и есть такой обьект управления. Он сам не принимает никаких решений, а просто сохраняет свои свойства и сохраняет состояние. Им управляют, а не он управляет, как субьект. Добавлено через 1 минуту Сообщение от korvin_ Не так. Да так оно и есть. Просто мы обьекты управления, но я понимаю, что это спорное положение для многих. 1

@CoderHuligan 1287 / 880 / 254 Регистрация: 30.06.2015 Сообщений: 4,593 Записей в блоге: 51
	13.12.2018, 17:05 [ТС]	4
	Сообщение от CoderHuligan Скорее всего понятие обьект возникло по аналогии с обьектом управления. Нет, скорее всего, эти люди просто либо не знали что существуют такие науки как Теория Управления и Кибернетика, либо делали это сознательно. Частным случаем последней является "изучение обратной связи, чёрных ящиков и производных концептов, таких как управление и коммуникация в живых организмах, машинах и организациях, включая самоорганизации. "(из вики). https://ru.wikipedia.org/wiki/Кибернетика Похоже на то, что эти науки вообще не учитывались при создании новой обьектной системы. Ведь совершенно очевидно что обьект управления не может являться самоуправляемой сущностью. Например имеем обьект управления "вентиль". Предположим, что он неизменен сам по себе. Этим вентилем может управлять не только какая-то то одна управляющая сущность, а множество таковых. Приведу пример. Создали мы обьект "вентиль" и запихнули туда определённый функционал(внутрь обьекта). Приходит управляющая сущность (УС), которая заточена именно на конкретный функционал вентиля (уже здесь стоит насторожится, ибо УС знает о внутреннем функционале), и начинает им управлять подавая команды: "открыть задвижку", "закрыть задвижку" и т.п. Со временем нам понадобился другой более расширенный функционал вентиля, к примеру, "открыть задвижку за 30 секунд", "закрыть задвижку на половину", "перейти в режим ожидания и ожидать 45 секунд" и т.п. В этом случае нам придётся вносить изменения во всю систему, что противоречит принципу открытости: "Программные сущности должны быть открыты для расширения, но закрыты для изменений." Что же произошло? УС часть своей ответственности переложила на обьект управления (ОУ). Она делегировала то, чем должна обладать сама самому этому ОУ жёстко заложив в нём конкретный функционал, который, по мысли этого УС должен выполнять обьект. Но тут появляется другая УС - УС-2 и говорит, что ей нужен другой, несколько отличный функционал, а место-то занято уже первым УС.. К чему я веду, а к тому, что обьект управления должен оставаться обьектом управления, и ничем больше. В таком случае управлять им могут множество разных УС, и это полностью будет соответствовать open/close принципу. ОУ закрыта для изменений, а ОУ открыта. При этом мы вводим не одно понятие обьекта, а два понятия: 1. Обьект управления. 2. Устройство управления. Добавлено через 2 часа 45 минут Добавлю, что есть такая наука - Теория автоматического управления (ТАУ), которая изучает эти вопросы сточки зрения математики: https://ru.wikipedia.org/wiki/... управления. Так вот, по этой теории, упрощённо можно разделить систему не на две составляющих, а на три(основных) это: 1. Обьект управления. 2. Устройство управления. 3. Регулятор. которые примерно располагаются в такой последовательности: Устройство управления > Регулятор > Обьект управления. Они могут быть связаны так называемыми обратными связями, например тот же регулятор и обьект. Но это слишком абстрактные понятия. Приведу пример. В реактивных системах, которые управляются конкретными пользователями(вне программы), устройством управления является сам этот человек-пользователь программы. В программе же остаются только ОУ и регуляторы. А в автоматических системах, которые управляются автоматически без участия человека, автоматическая система управления (АСУ) является целостной средой выполнения и включает в себя все эти три составляющие. Например в веб-приложениях CMS, форумных движках, применяется реактивные системы, которые реагируют на запросы пользователей, то бишь сами пользователи являются управляющими устройствами (УУ). Они не долгоживущие системы. Долгоживущие АСУ имеют место быть например в технологических процессах, в тех же игровых движках, которые управляют обьектами игрового мира продолжительное время. Математический аппарат, который описывает построение таких АСУ подробно разработан, и является надёжной базой для возможного построения непротиворечивых АСУ на существующих языках, или создания отдельного специального языка для описания систем управления. К сожалению такого языка ещё не создано. Однако это позволило бы привнести в область программирования достаточно разработанные научные методы. 1

@Грегори_ 14 / 17 / 1 Регистрация: 15.11.2018 Сообщений: 122
	24.12.2018, 14:33	5
	Сообщение от CoderHuligan В реальном мире в этой ситуации мы называем Васю субъектом. Хорошая книжка. Скорее всего понятие обьект возникло по аналогии с обьектом управления. Просто на него начали возлагать обязанности, которые присущи только субьектам. Это из терминологии кибернетики и теории управления https://ru.wikipedia.org/wiki/Объект_управления То есть произошла подмена понятий. "Обьект управления технической системы не выполняет функций принятия решений, то есть не формирует и не выбирает альтернативы своего поведения, а только реагирует на внешние (управляющие и возмущающие) воздействия, изменяя свои состояния предопределенным его конструкцией образом." (оттуда). А разве объект может? он ведь действует согласно предопределённым его конструкцией образом. Кто объект, а кто субъект- это тонкая философская тема. Если мы верим в спонтанность, свободу воли и существование выбора- человек это субъект. Если нет- то он действует по хитрым законам психики (которые мы пока не в состоянии понять полностью). А животные не слишком развитые живущие согласно инстинкту? Птицы? рыбы? Тараканы? === для меня это скорее удобный методический элемент для разложение мира на части при создании моделей. Можно отталкиваться от процессов. Можно- от объектов. Вопрос модели мышления. И её воплощения в программной системе. 0

@CoderHuligan 1287 / 880 / 254 Регистрация: 30.06.2015 Сообщений: 4,593 Записей в блоге: 51
	24.12.2018, 16:38 [ТС]	6
	Сообщение от Грегори_ Если мы верим в спонтанность, свободу воли и существование выбора- человек это субъект. Для меня человек, как и любое живое существо есть сложный набор статических данных, обьект управления. Устройство управления человека это его душа, что выражается его мыслительной деятельностью. Душа тоже управляется некой матрицей общих архетипов поведений. Над всем же стоит дух - Супер управляющий. Это сам человек в силу своей необразованности может считать себя субьектом, но это не так. Поэтому нужно разделять систему на две независимые сущности: 1. обьект управления и 2. управляющего субьекта. Обьект это статика. Субьект динамика. Человек находится в состоянии сна. Тело бездействует, а душа продолжает функционировать, и думать что не спит. Это говорит, что тело в целом, как форма это статическая система. Сообщение от Грегори_ А животные не слишком развитые живущие согласно инстинкту? Птицы? рыбы? Тараканы? Что есть инстинкт? Опять же это определённый архетип, который вступает в действие непосредственно, минуя стадию осмысления, сознания. Это побуждение к действию, которое слито с самим действием. Если бы сороконожка стала думать какой ногой сделать следующий шаг, то она бы не смогла двигаться. И человек наполовину состоит из инстинктов. Инстинкт это там, где выключается логический аппарат. Сообщение от Грегори_ Можно отталкиваться от процессов. Можно- от объектов. А можно от обоих. Совместно. Принять, что существуют отдельно обьекты управления и субьекты-управляющие этими обьектами. Это будет ближе к истине. 1

@Грегори_ 14 / 17 / 1 Регистрация: 15.11.2018 Сообщений: 122
	24.12.2018, 16:51	7
	Сообщение от CoderHuligan Над всем же стоит дух - Супер управляющий. Это сам человек в силу своей необразованности может считать себя субьектом, но это не так. Это ваши личные религиозные верования. С учётом того что они приводятся голословно- можно с тем же успехом утверждать что над всем стоит прародитель- крокодил. И кстати носители таких верований не меньше вашего убеждены в своей правоте. К объектам это естественно отношения не имеет 0

@CoderHuligan 1287 / 880 / 254 Регистрация: 30.06.2015 Сообщений: 4,593 Записей в блоге: 51
	24.12.2018, 17:04 [ТС]	8
	Сообщение от Грегори_ С учётом того что они приводятся голословно Они приводятся на основании моего собственного опыта. Поэтому они научны (для меня лично). Это моя наука. Она мне помогает в программировании. Ваша личная наука вам по всей видимости тоже помогает, но с другой стороны. Если вам легче мыслить в ООП стиле мыслите именно так. Я лично так мыслить не могу. Добавлено через 5 минут Вслед за индийскими философами я делю мир на Акашу и Прану, то есть на Вещество и Энергию. 1

@Pokomit_T 0 / 6 / 0 Регистрация: 15.12.2018 Сообщений: 102
	02.03.2023, 19:44	9
	где вы читали что прародитель - крокодил? 0

@eva2326 1536 / 456 / 101 Регистрация: 17.05.2015 Сообщений: 1,424
	04.03.2023, 20:36	10
	Сообщение от korvin_ В реальном мире в этой ситуации мы называем Васю субъектом. Объектом. Субъектом Вася является для самого себя, а для внешних наблюдателей он - объект. Субъект (от лат. subjectum «подлежащее»): Субъект в грамматике — подлежащее, семантическая категория со значением производителя действия или носителя состояния. Объект — философская категория, выражающая нечто, на что направлена практическая или познавательная деятельность субъекта (наблюдателя). 0

@Ludwig Valentin Matthias Ronald Gerard 149 / 209 / 25 Регистрация: 11.08.2022 Сообщений: 2,073
	08.03.2023, 04:29	11
	Дело в подходе к программированию. В реальном мире всё есть объект и в программировании тоже можно всё описать объектами. Это дело аналитика. Существует же язык UML, описывающий реальный мир формализованным языком. Дело аналитика - описать реальное явление, которое мы хотим смоделировать и зафиксировать его свойства. Далее дел за программированием - классы, свойства, методы, события. Классы взаимодействуют друг с другом и порождают события. Каждое событие надо корректно обработать - вот вам и всё ООП. Наследование - обобщение - генерализация позволяют наследовать разные классы с индивидуальными общими свойствами от едино предка. Это позволяет повторно использовать код предка. Разумеется, методы могут быть виртуальными и их можно переопределять - и это тоже предусмотрено в продвинутых языках программирования. На философии ООП построены RAD - инструменты быстрой разработки приложений. Окна и контролы взаимодействуют между собой, генерируют свои события. Всё довольно просто, надо только взобраться на следующий уровень абстракции. Естественно, объектно-ориентированный подход требует большей мощности процессора и параллельных вычислений, но ведь технический прогресс не стоит на месте. Не надо кодировать на ассемблере или процедурном языке, когда есть ООП. И, кроме того, такой подход позволяет экономить время и средства при проектировании и кодировании. 0

@Ludwig Valentin Matthias Ronald Gerard 149 / 209 / 25 Регистрация: 11.08.2022 Сообщений: 2,073
	08.03.2023, 09:29	13
	Сообщение от eva2326 Это бред. Раз вы такое написали, то вероятно вы думаете, что под капотом объектно ориентированных языков какая то магия ?)) И вот эта магия, что бы поддерживать ооп требует каких то дополнительных ресурсов? Чушь! Поддержка оо-программирования в оо-языках - это всего лишь синтаксический сахар, реализуемый поверх обычной процедурной парадигмы. Например, первые компиляторы с++ по началу транслировали код на язык си. Тобишь, убирали всю эту оппнутую мишуру, обнажая его процедурную суть. И только спустя какое то время, начали транслировать сразу в машкоды. ну и что, что в процедуры преобразовывает? так этих процедур на порядок больше. процессор выполняет команду, которыу ему написали - с этим согласен а вот написать компилятор объектно-ориентированного языка - это нетривиальная задача. Сообщение от eva2326 Любую языковую оо-конструкцию всегда можно описать в процедурном стиле, причем используя исключительно статическую типизацию. И кстати, вообще, абсолютно любую существующую на сегодняшний день языковую конструкцию, можно описать на процедурном си. Потому что все, без исключения, существующие на сегодняшний день парадигмы, базируются на теплом и ламповом процедурном императиве. Но у вас же хватает ума не заявлять, будто бы "процедурный подход требует большей мощности процессора и параллельных вычислений", зачем же вы такую чушь про ооп написали? прогресс - от сатаны говорите? а вы фильтруйте технологию, оставляйте хорошее и полезное или я получаюсь прагматиком? если вы про коллегу, то подписываю коллегу у меня университетский диплом. а англичане так и говорят колледж. если вы против прогресса, давайте перейдём на ламповый ЭНИАК. он вполне справлялся с расчётом артиллерийских таблиц 0

@escoult 1519 / 462 / 126 Регистрация: 09.01.2018 Сообщений: 1,094
	08.03.2023, 13:51	14
	Сообщение от eva2326 И вот эта магия, что бы поддерживать ооп требует каких то дополнительных ресурсов? Чушь! Как-то в 2018 мы в ветке С# решали олимпийскую задачку ("Коррупция"). Проблема была влезть в лимит времени (100 мс, 64 MiB). Решалась написанием своих методов Parse, Split и сортировки. Таким образом удавалось втиснуться в 100 мс, результаты были 83 мс, 92 мс, около того, и примерно 30 MiB памяти. В этом году она мне вспомнилась, и я решил переписать ее на С. Используя тот же алгоритм, результаты 2 мс и 500 кб памяти. Потом подумал, а можно ли еще меньше. Повозился с алгоритмом, снизил до 176 кб. Разница с "магией" в разы. 0

@eva2326 1536 / 456 / 101 Регистрация: 17.05.2015 Сообщений: 1,424
	08.03.2023, 14:54	15
	Сообщение от escoult Разница с "магией" в разы. Нелогичным людям свойственно путать С# с "магией". 0

@escoult 1519 / 462 / 126 Регистрация: 09.01.2018 Сообщений: 1,094
	08.03.2023, 15:27	16
	Сообщение от eva2326 Нелогичным людям свойственно путать С# с "магией". Слава Б-гу, что хоть не начали "просвящять" меня и рассказывать что такое .NET и как он работает. )) 0

@Ludwig Valentin Matthias Ronald Gerard 149 / 209 / 25 Регистрация: 11.08.2022 Сообщений: 2,073
	08.03.2023, 21:09	19
	Сообщение от eva2326 Нелогичным людям свойственно путать С# с "магией". это, извините, маразм ну подумайте хоть немного нелогичных программистов не бывает. представьте себе блок-схему алгоритма - workflow. логика железная. 0

@Ludwig Valentin Matthias Ronald Gerard 149 / 209 / 25 Регистрация: 11.08.2022 Сообщений: 2,073
	08.03.2023, 21:20	20
	довожу до вашего сведения пример блок-схемы Миниатюры 0