Что делает ООП - ООП?

http://rylev.github.io/words/blog/2013/10/03/erlang-is-the-most-object-orient...

TL;DR: OO is only about message passing and isolation and protection of state.

ѣООП

ЕООП?

но не могу не задать вопроса, зачем наследование вообще нужно использовать?

Если отвечать просто, то можно выделить 3 причины:

1) Совместное использование кода

2) Метаобъекты (для динамических яп)

3) Удобное построение абстракций

Три кита ООП:
1. Легко обучать тысячи code monkeys.
2. Несмотря на следствие из пункта 1, большие проекты со временем не разваливаются от груза кодовой базы.
3. Условная GoF в состоянии состряпать талмуд, помогающий осуществиться пунктам 1 и 2.

Это все так, но ты говоришь про *другое* *так называемое* ООП.

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

это же анонiмус

Как найти ту тонкую грянь которая разделит ОО-код от иного?

Ее не существует. Методологии свободно смешиваются в коде.

Степень ОО-сти определяется количеством остальных примесей.

Я в курсе :}

1) Совместное использование кода

Вот так прямо часто нужно? Решает ли оно эту проблему?

2) Метаобъекты (для динамических яп)

Здесь да, сложно спорить

3) Удобное построение абстракций

Удобное? Слаще морковки ничего не пробовал?

Ну вот, в конце концов, что думает Госслинг (автор джавы) о наследовании: https://books.google.ru/books?id=uR1es8pL8XwC&pg=PA38&lpg=PA38&dq...

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

Какие вещи специфичны только для ООП?

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

Нет, модуль — не объект. Модуль содержит информацию о типе и операциях над ним, при этом не существует никаких экземпляров модуля, инкапсулирующих состояние. Данные отдельно, функции отдельно, и при том никаких проблем с повторным использованием кода и наследованием.

при этом не существует никаких экземпляров модуля, инкапсулирующих состояние

А я где-то об этом говорил?

Нет, модуль — не объект

Не объект в смысле синтаксиса, но семантически он объект.

семантически он объект

Нет. Совсем. Как модуль может быть объектом, если он является описанием типа и определенных над ним операций? Или для тебя класс и объект — одно и то же?

Или для тебя класс и объект — одно и то же?

Вообще-то да, класс является семантически объектом, а в некоторых языках и синтаксически тоже.

давно уже не люблю понятие 'семантика' в контексте программирования т.к. каждый фантазёр оправдывает ей всякий бред

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

правильно (в смысле функционирования кода) == предсказуемо

тип и объект типа — не одно и то же.

Да, это разные вещи. Но кто мешает типу в свою очередь так же быть объектом?

а что его сделает объектом?

Зачем ты спрашиваешь у «людей со слабой математической подготовкой»? Они не дадут тебе ответа.

а вдруг дадут :-O

а что его сделает объектом?

Посмотри на те языки, где классы являются объектами.

Зачем ты спрашиваешь у «людей со слабой математической подготовкой»? Они не дадут тебе ответа.

С чего ты взял, что у того анона слабая мат. подготовка? Тем более, что мы тут скорее инженерные вещи обсуждаем, а не голую математику. Грубо говоря, разговор о SE, а не о CS.

Какого анона? Ладно, допускаю, что у того анона сильная. Но тема ОП тухлая.

ООП это подход, а не языковые конструкции. Gtk - это ООП. Ядро линукса - тоже ООП.

здравый смысл говорит, что тип и объект типа — не одно и то же

Яблоня и яблоко не одно и тоже, но оба объекты. Просто не надо путать частное понятие инстанс, и общее понятие объект.

а что его сделает объектом?

Я сделаю, когда буду рассматривать его в смысле объекта. Объект понятие чисто смысловое, не относящееся к синтаксису языка. К синтаксису относится понятие инстанс. Инстанс класса/типа конечно является объектом и в тех языках, где сам класс/тип нельзя синтаксически использовать как объект, техническое понятие инстанса и философское понятие объекта смешиваются, т.к. в этих языках они равнозначны.

Я сделаю, когда буду рассматривать его в смысле объекта.

Во, отлично! кажется я понял что такое ООП — это способ мышления, а является ли код ООП — всегда субъективно и зависит от того кто с ним работает, причём один и тот же код может быть как ООП, так и не ООП в один момент времени
Всё так?

Вообще языки, где всё является объектом - классы, модули, простые типы вроде чисел, функции выглядят более тру ООП, чем императивные языки с прикрученными сбоку классами как C++.

Посмотри на те языки, где классы являются объектами.

это не ответ

и наследование и инкапсуляция и полиморфизм есть и в языках не считающихся ООП

Протестую - мультипарадигменные языки - это чит ;-)

мультипарадигменные языки

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

ООП — это способ мышления

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

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

а если наследования нет?

выглядят более тру ООП, чем императивные языки с прикрученными сбоку классами как C++

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

а если наследования нет?

Это вырожденный случай, но формально всё равно можно считать за ООП.

т.е. если ещё упростить — ооп это когда есть есть функция, у который есть неявный аргумент 'название_метода' и свитч внутри?

ооп это когда есть есть функция, у который есть неявный аргумент 'название_метода' и свитч внутри?

Да, только свитч снаружи - диспетчер.

неявный аргумент

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

Кажется, нас таких только двое %)

Первый параметр функции перед функцией. Для инкапсуляции/полиморфизма/наследования ООП не требуется.

Яблоня и яблоко

Какая тупая аналогия.

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

структура - это класс, все члены которого общие

По умолчанию, можно сделать private. Кстати, меня всегда поражал public в самом начале класса, ну бред же.

С яйцом и курицей не известно наверняка кто был раньше

Известно, яйцо-мутант.

Как говорит народная мудрость, не зарекайся.

проза - это стихи без рифмы

я вот не понял

объекты определяются не внутренним устройством, а совокупностью взаимодействий

любой (наилучший в некотором смысле) объект, из которого можно построить проекции на множества A и B, является декартовым произведением множеств A и B. ни слова о том, сколько таких объектов есть - или о том, как они устроены. пока выполняются внешние (в смысле леммы Йонеды) условия, всё остальное иррелевантно

любой (удовлетворяющий некоторым constraint'ам) объект, реализующий необходимый нам интерфейс, является подходящим. опять же, ни слова о том, как этот объект устроен, сколько разных объектов могут удовлетворять интерфейсу, где физически находится вычислитель который выполняет его методы. пока выполняются внешние условия, всё остальное иррелевантно

как описать интерфейс взимодействий - наследованием, реализацией интерфейса, прототипированием, контрактами, теоремами о поведении, неявным множеством операций - неважно. как выполнять поиск исполнителя - поиском по vtbl, какой-то реализацеий делегирования, ORB'ом, blackboard'ом - неважно

ОО программирование - это программирование на языке предпучков предметной области. в этом смысле Erlang - очень ОО язык, C++ существенно менее ОО язык

Нет, ты, кажется, вообще не понимаешь, что такое тип и класс

Нет ты.

Яблоко, которое ты держишь в руке — объект, а описание яблока, его свойств — тип, между ними нет разницы?

Нет. Описание я тоже держу в руке.

Нет ты.

Ну судя по тому, что ты сравниваешь яблоню с типом, а яблоко с классом — не понимаешь. Яблоня — не описание и не тип яблока.

Нет. Описание я тоже держу в руке.

Ты не можешь держать в руке описание, ты можешь держать в руке листок бумаги или что-то подобное, содержащее вербальное или еще какое представление описания, текст или рисунок. У тебя большие проблемы со способностью отличать verba и res, имя и суть, средневековый тип мышления, кстати.