Объясните понятие ООП

@KrisMuS · Регистрация: 02.10.2019

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

Скажите пожалуйста понятным языком, что такое объектно-ориентированное программирование ?

@Shamil1 · 21.10.2020, 00:53

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

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

Тогда, по-Вашему, и модуль - "по сути объект", и все языки - ООЯП.

@korvin_ · 21.10.2020, 08:57

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

Как это не имею?

Так же не имеешь, как и про ООП.

@Shamil1 · 21.10.2020, 17:04

Если говорить об объектном (возможно, но необязательно, объектно-ориентированном) проектировании, то у нас нет таких понятий как код и данные. Мы выполняем операции (действия) над объектами, вызывая специальные функции ("вызываем методы объектов" или - то же самое другими словами - "отправляем объектам сообщения"). Данных нет, есть состояние, и это состояние может быть где угодно. Свойства объектов - это синтаксический сахар для особых функций - геттеров и сеттеров. Нам не важно (на этапе проектирования), откуда эта функция возьмёт нужное значение - из оперативной памяти, из базы данных или запросит через СМС расположенный в каком-то помещении датчик. Кстати, код метода тоже может находиться на другом компьютере (а на нашем - автоматически сгенерированный прокси).

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

Итого:
1. Объекты не объединяют код и данные. Состояние может быть описано в одном месте, а операции определены в другом.
2. Объекты используются не только в ООП. Любой Абстрактный Тип Данных по сути описывает объекты.

@Mikhaylo · 22.10.2020, 07:33

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

Каша!

@Shamil1 · 22.10.2020, 10:46

Ваши определения вредны, так как не верны. Вы сильно сужаете.

Аналогия:
Вы утверждаете, что завтрак - это кофе с булочкой. Но из этого следует, что если кто-то ест кофе с булочкой, то он завтракает. А если он ест овсянку, то не завтракает. И время суток не имеет значения.

Что сложного в понятиях "состояние" и "функция"?
"Передача сообщения" - так Алан Кэй называет вызов метода. Ничего сложного - достаточно один раз услышать и запомнить.

Код и функции - разные понятия.

JavaScript
1
2
3
var code = "2 + 2";
var result = eval(code);
console.log(result);

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

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

C#
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
public double F1(double x)
{
    var y = x*x;
    return Math.Cos(y) + Math.Sin(y);
}
 
public double F2(double x)
{
    double f(double y) => Math.Cos(y) + Math.Sin(y);
    return f(x*x);
}
 
public double F3(double x) => (x*x).In(y => Math.Cos(y) + Math.Sin(y));
 
 
public static class Helper
{
    public static T2 In<T1,T2>(this T1 x, Func<T1,T2> f) => f(x);
}

@vantfiles · 22.10.2020, 10:52

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

Объекты не объединяют код и данные. Состояние может быть описано в одном месте, а операции определены в другом.

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

@Shamil1 · 22.10.2020, 11:06

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

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

Да. Связаны. Операции используют состояние (и, возможно, меняют его).

C#
1
2
3
4
5
6
7
8
9
public class A
{
    const string file = @"d:\Temp\1.txt";
    public string Prop
    {
        get => File.ReadAllText(file);
        set => File.WriteAllText(file, value);
    }
}

Состояние есть, а переменных нет.

Добавлено через 53 секунды

C#
1
2
3
4
5
public double F1(double x)
{
    var y = x*x;
    return Math.Cos(y) + Math.Sin(y);
}

Переменные есть, а состояния нет.

@korvin_ · 22.10.2020, 11:31

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

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

Но так можно сказать вообще про всё. )

@Shamil1 · 22.10.2020, 11:41

vantfiles,
По поводу якобы определения от Mikhaylo я сразу сказал, что это не определение, а объяснение "на пальцах".

Аналогия:
"Мяч - это спортивный снаряд шарообразной формы."
Для объяснения на пальцах сойдёт, но это ни разу не определение. Во-первых, мяч может иметь другую форму (регби). Во-вторых, шарообразную форму может иметь другой спортивный снаряд (ядро).

@korvin_ · 22.10.2020, 11:42

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

"Передача сообщения" - так Алан Кэй называет вызов метода.

Не совсем. «Передача сообщения» чуть более абстрактный термин, методов как процедур-реакций на отдельные сообщения может и не быть, а объект может иметь только одну «процедуру» — dispatch, которая разбирает любые полученные сообщения и что-то с ними делает в том или ином виде.

Примеры:
– Erlang
– простая объектная модель на замыканиях, вроде моего примера на Scheme выше, хоть там и есть слово method и объект описывается набором методов, это просто синтаксический сахар для match/case.
– на Oberon/Component Pascal часто ООП так и делают: определяют union-тип Message, который является аргументом единственного «метода» record-объекта, а внутри — typecase.

@Shamil1 · 22.10.2020, 14:21

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

чуть более абстрактный термин, методов как процедур-реакций на отдельные сообщения может и не быть, а объект может иметь только одну «процедуру» — dispatch

В динамических ЯП вызов метода примерно так и организован.

C#
1
2
3
    dynamic sampleObject = new ExpandoObject();
    sampleObject.SampleMethod = (Func<int,int>) (x => x * 2);
    Console.WriteLine( sampleObject.SampleMethod(10) ); // 20

Выглядит, как будто у sampleObject есть метод SampleMethod.

@neya · 24.10.2020, 12:58

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

из того, что Вы используете объекты, не следует, что Вы используете ООП.

Да, сегодня нашёл прямым текстом: "Парадигмы перпендикулярны".

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

замыкание является объектом

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

@Mikhaylo · 25.10.2020, 09:24

Объекты, которые дополнили переменные, функции и структуры полнотой, привели к ООП. И тут программеры, не несклонные к строгому мышлению, "полетели в небеса". Полет в небесах настолько привлекателен для новичков - тебе говорят сладкие речи про концепции, принципы, инструменты, моделирование вселенной, наследование, ~~эволюцию~~, абстракции...

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

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

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

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

А у вас некие штуки обмениваются сообщениями в каком-то пространстве.

Как подметил Даня Рогозин: на самом деле, есть более общая проблема, что люди очень редко умеют давать точные определения, а сразу идут к примерам по личным ассоциациям.

Отсюда цитата:
https://medium.com/devschacht/... 07d9f9cd78

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

Я скажу более: программист - это такое существо... В его голове изначально каша.

@korvin_ · 25.10.2020, 09:56

Mikhaylo, каша в голове тут только у тебя.

@Mikhaylo · 25.10.2020, 10:14

korvin_,

Добавлено через 1 минуту
"Объекты обмениваются сообщениями." (с)

Зеленые человечки разговаривают.

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

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

Аналогия:
Вы утверждаете, что завтрак - это кофе с булочкой. Но из этого следует, что если кто-то ест кофе с булочкой, то он завтракает. А если он ест овсянку, то не завтракает. И время суток не имеет значения.

Аналогия неверная.

Я сказал, что статический класс - это тоже объект. То есть мое определение более широкое, а вы мне тут противоположную аналогию всераете про завтрак и булочку.

А к черту аналогии, головой-то можно подумать? Есть определение и оно выступает как аксиома. Если весь мир дал определение для "кофе с булочкой", то нафига вы завтрак приплетаете не к месту? Или почему у вас статический класс вызывает когнитивный диссонанс, ведь вы должны смотреть не на название, а на суть.

@korvin_ · 25.10.2020, 10:25

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

"Объекты обмениваются сообщениями." (с)
Зеленые человечки разговаривают.

Не моя проблема, что ты не способен это понять. Каша в голове начинает замещать тебе мозг?

@Mikhaylo · 25.10.2020, 10:28

Это я про кашу в голове высказался, ибо я знаю об этом не мало, ты почему за мной повторяешь как попугай?

@korvin_ · 25.10.2020, 10:47

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

Это я про кашу в голове высказался, ибо я знаю об этом не мало

Это заметно.

@vantfiles · 25.10.2020, 14:44

Объясните понятие ООП

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

"некие штуки обмениваются сообщениями"

Ну да. В Smalltalk можно классу назначить обработчик сообщения "по умолчанию". Это похоже на default из switch-case.
В С++ и его клонах это немыслимо.

"Композиция - это когда"

В прототипном ООП можно использовать декомпозицию. Это когда после наследования поля и методы не добавляются - а удаляются. Например - берем самолет, от него наследуем планер - и снимаем с наследника мотор.

@Shamil1 · 26.10.2020, 09:50

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

Ну да. В Smalltalk можно классу назначить обработчик сообщения "по умолчанию". Это похоже на default из switch-case.
В С++ и его клонах это немыслимо.

Не только в Smalltalk, но и в большинстве языков с динамической типизацией. Например, в питоне "__getattr__(self, name)" и т.п.

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

В прототипном ООП можно использовать декомпозицию. Это когда после наследования поля и методы не добавляются - а удаляются.

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

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

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

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

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

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

То есть мое определение более широкое

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

Есть определение и оно выступает как аксиома. Если весь мир дал определение для

Противоречие. Весь мир дал определение объекту, а Вы придумали своё "более широкое". И теперь настаиваете, что оно верное.

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

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

Перегрузка функций - всего лишь один из видов полиморфизма. Это разновидность ad hoc полиморфизма - для разных типов выполняется разный код - противопоставляется истинному полиморфизму, когда один и тот же код выполняется для разных типов. Перегрузка функций ортогональна ООП. ООП использует полиморфизм подтипов.

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

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

"Объекты обмениваются сообщениями." (с)
Зеленые человечки разговаривают.

Это общепринятая терминология. Кстати, дальнейшее развитие ООП - это когда объекты могут обмениваться сообщениями высшего порядка (higher order message, HOM). То есть, когда сообщения могут быть аргументами других сообщений.

Новые блоги и статьи Все статьи Все блоги /
сукцессия 29. Переход от одних деревьев на другие делать более или менее вероятностным? anaschu 12.07.2026 Насколько смена типов микоризы — исключительное событие в двухвековой сукцессии? Оценка вероятности в пространстве параметров В текущей версии модели успешно реализован ключевой механизм. . .	сукцессия 27. Думаю, как переделывать уже написанную статью с планами на сукцессию. anaschu 12.07.2026 Анализ соответствия модели требованиям Реализованные компоненты: Механизм закисления почвы через протонную помпу Конкуренция между типами микориз pH как триггер сукцессии C/ P соотношение. . .	Сукцессия 26. Мат модель создана. anaschu 12.07.2026 Модель смены растительных сукцессий посредством управления грибами работает внутри небольшой ячейки почвы, восстанавливающейся после пожара, где ненадолго бывшее царство хвойных снова захватили. . .	Решил проблему с ошибкой пагинации сообщений с сервера на алгоритме обхода дерева "Эстафета хвоста". Hrethgir 12.07.2026 Проблема была в том, что удалялась именно новая кнопка, а не старая. Ни один ИИ не обнаружил это, а сам я смог только когда с работой стало попроще и когда заставил работать будущее автономное. . .
сукцессия 25. Хронология ошибок anaschu 12.07.2026 # От 50-тонного гриба до устойчивого леса: хроника ошибок при построении модели вековой сукцессии микоризы ## О чём эта статья В процессе построения ОДУ-модели (система дифференциальных. . .	сукцессия 24. Промежуточное общее описание модели anaschu 12.07.2026 Хендофф: модель АМ→ЭКМ сукцессии микоризы (ризосфера, 50 лет) Содержание проекта Симуляция вековой (50 лет) экологической сукцессии в почве леса Основные участники: АМ-гриб, ЭКМ-гриб,. . .	сукцессия 23. Более физиологичная физиология, более экологичная экология, более диффурные диффуры. anaschu 12.07.2026 Что реально нашли и починили за эти 5 часов Правило Линдемана (КПД конверсии сахара в тело, kEff) — раньше 100% полученного углерода шло прямо в биомассу гриба; теперь только kEff=0. 5 (после. . .	сукцессия 22. От артефактов к физиологии: калибровка агентной модели грибной сукцессии для воспроизведения сезонной динамики и pH-плато anaschu 11.07.2026 Аннотация В данной работе представлена калибровка агентной модели динамики грибных сообществ (fungal-succession), направленная на устранение нефизичных артефактов (коллапс биомассы, мгновенное. . .

@KrisMuS 0 / 0 / 0 Регистрация: 02.10.2019 Сообщений: 20

	Объясните понятие ООП 13.02.2020, 23:25. Показов 21396. Ответов 242 Метки значение, новичёк, ООП, термин (Все метки) Скажите пожалуйста понятным языком, что такое объектно-ориентированное программирование ? 0

@Shamil1 Модератор 3140 / 2288 / 469 Регистрация: 26.03.2015 Сообщений: 8,898
	21.10.2020, 17:04
	Если говорить об объектном (возможно, но необязательно, объектно-ориентированном) проектировании, то у нас нет таких понятий как код и данные. Мы выполняем операции (действия) над объектами, вызывая специальные функции ("вызываем методы объектов" или - то же самое другими словами - "отправляем объектам сообщения"). Данных нет, есть состояние, и это состояние может быть где угодно. Свойства объектов - это синтаксический сахар для особых функций - геттеров и сеттеров. Нам не важно (на этапе проектирования), откуда эта функция возьмёт нужное значение - из оперативной памяти, из базы данных или запросит через СМС расположенный в каком-то помещении датчик. Кстати, код метода тоже может находиться на другом компьютере (а на нашем - автоматически сгенерированный прокси). Причём, всё это относится не только к ООП, но и к любым другим методологиям объектного проектирования. При императивном подходе вызываемые функции будут менять состояние объекта. При функциональном подходе вызываемые функции будут возвращать новое состояние объекта. В обоих случаях состояние объекта можно сделать неявным аргументом наших специальных функций. В качестве контейнера для операций может служить не только класс, но и модуль, пакет и т.д. - вплоть до массива адресов перехода. Итого: 1. Объекты не объединяют код и данные. Состояние может быть описано в одном месте, а операции определены в другом. 2. Объекты используются не только в ООП. Любой Абстрактный Тип Данных по сути описывает объекты. 0

@Mikhaylo 820 / 579 / 75 Регистрация: 20.09.2014 Сообщений: 3,814
	22.10.2020, 07:33
	Ваши определения бесполезны, так как вы применяете абстракции (замены-синонимы), которые никто не понимает правильно и однозначно. При этом вам непонятны абстракции "переменные => данные", "функции => код", зато понятны абстракции "передача сообщений". В итоге вы отвергаете что-то конкретное, не вводите ничего взамен, надстраиваете что-то абстрактное и непонятное и довольны, якобы точных определений быть не может. Каша! 0

@Shamil1 Модератор 3140 / 2288 / 469 Регистрация: 26.03.2015 Сообщений: 8,898
	22.10.2020, 11:41
	vantfiles, По поводу якобы определения от Mikhaylo я сразу сказал, что это не определение, а объяснение "на пальцах". Аналогия: "Мяч - это спортивный снаряд шарообразной формы." Для объяснения на пальцах сойдёт, но это ни разу не определение. Во-первых, мяч может иметь другую форму (регби). Во-вторых, шарообразную форму может иметь другой спортивный снаряд (ядро). 0

@korvin_ 4576 / 2775 / 491 Регистрация: 28.04.2012 Сообщений: 8,781
	25.10.2020, 09:56
	Mikhaylo, каша в голове тут только у тебя. 0

@Mikhaylo 820 / 579 / 75 Регистрация: 20.09.2014 Сообщений: 3,814
	25.10.2020, 10:28
	Это я про кашу в голове высказался, ибо я знаю об этом не мало, ты почему за мной повторяешь как попугай? 0

@vantfiles 1018 / 1921 / 177 Регистрация: 07.05.2013 Сообщений: 3,931 Записей в блоге: 12
	25.10.2020, 14:44
	Объясните понятие ООП Вот это определение не вызывает у меня возражений. Просто хочется прокомментировать. "некие штуки обмениваются сообщениями" Ну да. В Smalltalk можно классу назначить обработчик сообщения "по умолчанию". Это похоже на default из switch-case. В С++ и его клонах это немыслимо. "Композиция - это когда" В прототипном ООП можно использовать декомпозицию. Это когда после наследования поля и методы не добавляются - а удаляются. Например - берем самолет, от него наследуем планер - и снимаем с наследника мотор. 0