Три кита ООП:
1. Легко обучать тысячи code monkeys.
2. Несмотря на следствие из пункта 1, большие проекты со временем не разваливаются от груза кодовой базы.
3. Условная GoF в состоянии состряпать талмуд, помогающий осуществиться пунктам 1 и 2.
Это гораздо более значащая позиция, чем мнение рабов-кодеров пашущих от зари до зари, да ещё обычно имеющих слабую математическую подготовку, что с очень большой вероятностью сигнализирует о неспособности к грамотной абстракции.
Нет, модуль — не объект. Модуль содержит информацию о типе и операциях над ним, при этом не существует никаких экземпляров модуля, инкапсулирующих состояние. Данные отдельно, функции отдельно, и при том никаких проблем с повторным использованием кода и наследованием.
Нет. Совсем. Как модуль может быть объектом, если он является описанием типа и определенных над ним операций? Или для тебя класс и объект — одно и то же?
Зачем ты спрашиваешь у «людей со слабой математической подготовкой»? Они не дадут тебе ответа.
С чего ты взял, что у того анона слабая мат. подготовка? Тем более, что мы тут скорее инженерные вещи обсуждаем, а не голую математику. Грубо говоря, разговор о SE, а не о CS.
Я сделаю, когда буду рассматривать его в смысле объекта. Объект понятие чисто смысловое, не относящееся к синтаксису языка. К синтаксису относится понятие инстанс. Инстанс класса/типа конечно является объектом и в тех языках, где сам класс/тип нельзя синтаксически использовать как объект, техническое понятие инстанса и философское понятие объекта смешиваются, т.к. в этих языках они равнозначны.
Я сделаю, когда буду рассматривать его в смысле объекта.
Во, отлично! кажется я понял что такое ООП — это способ мышления, а является ли код ООП — всегда субъективно и зависит от того кто с ним работает, причём один и тот же код может быть как ООП, так и не ООП в один момент времени
Всё так?
Вообще языки, где всё является объектом - классы, модули, простые типы вроде чисел, функции выглядят более тру ООП, чем императивные языки с прикрученными сбоку классами как C++.
Разумеется, но дело в том, что есть не только ООП как таковое, но и ООП языки, которые имеют синтаксическую поддержку этого подхода, которая часто устроена очень по-разному. Отсюда и споры школьников, что ООП, а что нет - каждый силится доказать, что ООП это то, как устроена поддержка ООП в язычке, по которому этот пионэр прочитал мурзилку.
Как я уже сказал, на мой взгляд обязательным для ООП вообще является только диспатчинг финкции по дереву наследования, т.е. вызов функции в контексте некоторого инстанса. Как конкретно выбирается этот инстанс - дело десятое.
выглядят более тру ООП, чем императивные языки с прикрученными сбоку классами как C++
Вовсе нет. Всё объект - это технический уровень, конкретика. Причём зачастую такой подход, когда пытаются всё вывести/объяснить одним универсальным способом оказывается и переусложнённым и неэффективным. Обычно специальные решения лучше. И это касается не только программирования.
Нет, ты, кажется, вообще не понимаешь, что такое тип и класс. Яблоко, которое ты держишь в руке — объект, а описание яблока, его свойств — тип, между ними нет разницы?
объекты определяются не внутренним устройством, а совокупностью взаимодействий
любой (наилучший в некотором смысле) объект, из которого можно построить проекции на множества A и B, является декартовым произведением множеств A и B. ни слова о том, сколько таких объектов есть - или о том, как они устроены. пока выполняются внешние (в смысле леммы Йонеды) условия, всё остальное иррелевантно
любой (удовлетворяющий некоторым constraint'ам) объект, реализующий необходимый нам интерфейс, является подходящим. опять же, ни слова о том, как этот объект устроен, сколько разных объектов могут удовлетворять интерфейсу, где физически находится вычислитель который выполняет его методы. пока выполняются внешние условия, всё остальное иррелевантно
как описать интерфейс взимодействий - наследованием, реализацией интерфейса, прототипированием, контрактами, теоремами о поведении, неявным множеством операций - неважно. как выполнять поиск исполнителя - поиском по vtbl, какой-то реализацеий делегирования, ORB'ом, blackboard'ом - неважно
ОО программирование - это программирование на языке предпучков предметной области. в этом смысле Erlang - очень ОО язык, C++ существенно менее ОО язык
Ну судя по тому, что ты сравниваешь яблоню с типом, а яблоко с классом — не понимаешь. Яблоня — не описание и не тип яблока.
Нет. Описание я тоже держу в руке.
Ты не можешь держать в руке описание, ты можешь держать в руке листок бумаги или что-то подобное, содержащее вербальное или еще какое представление описания, текст или рисунок. У тебя большие проблемы со способностью отличать verba и res, имя и суть, средневековый тип мышления, кстати.