Зачем нужно ООП

а правила сравнения

… у тебя наверное тоже объект, да? С инкапсуляцией и полиморфизмом небось?

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

чувак, не хочешь немного приватных членов класса?

С какой стати компаратор должен стать приватным членом класса? И кто вообще сказал, что он обязан быть членом класса?

http://www.stroustrup.com/bs_faq.html#bootstrapping

В смысле его назначение было бустрап компилятора.

А зачем объект там, где достаточно функции?

не замкнутый ли круг тут получается?

Замкнутый круг это тоже объект. Ничего страшного.

А почему функция не объект?

Зачем нужно ООП (комментарий)

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

f = это функция или объект?

объект. просто прикрутили синтаксис сбоку и назвали его функторами (если я не путаю, уже лет 5 не брал в руки ооп).

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

Функция как объект с оператором вызова

Смею отметить, что в определении ооп нет никаких „операторов“. Это термин языка. Вот если бы ты написал просто „функция как объект“ тогда с тобой можно было бы вести какой-то диалог. А так - аргументы не очень.

Замкнутый круг в чистом виде и есть. Если метод - тоже объект, то у него есть метод call, который тоже объект, у которого тоже есть метод call и т.д. Возможно, это теоретически интересно, но на практике ты это не реализуешь. Должен быть фундамент. Атомы какие-то.

f - объект-функция. Я спрашивал про метод <call>, который так же можно считать функцией, которая принимает/захватывает this, но тогда его можно рассматривать тоже как объект.

В будущем может стать не «достаточно».

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

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

Таки всё свелось к «я не люблю выгребать за собой своё дерьмо».

Длительный рефакторинг в сложной модели - плата за жесткую типизацию, которая предназначена в том числе и для того, чтобы отсеять кучу ошибок и опечаток - зато ты точно не получишь «NoSuchPropertyException».

Вполне разумная плата.

Зато получишь NullPointerException.

Очевидно же. Если draw(circle) и draw(rectange) работают правильно, то в circle и rectange есть байтик по которому draw их различает. Чудес не бывает.

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

класс
отнаследую
виртуальный
переопределю

Я про объекты говорил, а не про классы/наследование/полиморфизм/прочие_баззворды. «Булочная», «булка», «девочка», «Яна», «подружка» и так далее — это всё объекты. Не в смысле ООП, а в бытовом смысле: хреновины, каждая из которых обладает какими-то качествами (булка съедобная, яна смешная), находится в каком-то состоянии (булка заплесневела, яна бодра и весела), может определенным образом взаимодействовать с окружающим миром (яна может сожрать булку), и так далее. Это очень естественный для людей, врожденный взгляд на окружающий мир. Части речи - существительные, глаголы, прилагательные, и так далее — как раз все выстроены вокруг этого подхода.

ооп для графики хорошо подходит

Чем же? Для GUI всяких(и не только) FRP хорошо подходит.

Таки всё свелось к «я не люблю выгребать за собой своё дерьмо».

таки свелось к тому, что я предпочитаю бороться с целью задачи, а не с её средством решения.

Длительный рефакторинг в сложной модели - плата за жесткую типизацию, которая предназначена в том числе и для того, чтобы отсеять кучу ошибок и опечаток - зато ты точно не получишь «NoSuchPropertyException».

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

Чем же?

чёткостью иерархии.

Я спрашивал про метод <call>, который так же можно считать функцией, которая принимает/захватывает this, но тогда его можно рассматривать тоже как объект.

А ты назови <call> не функцией, а «вычислением» - и тебе станет легче.

function power_it(base) (arg) {
    return power(base,arg);
}
function square = power_it(2);
function volume = power_it(3);
print "square=", square(3), " volume=", volume(3);

class power_it {
    int base;
    power_it(int base) { this.base = base; }
    int power(a) { return Math.power(a,base); }
}
power_it square = new power_it(2);
power_it volume = new power_it(3);
print "square=", square.eval(3), " volume=", volume.eaval(3);

Я про объекты говорил, а не про классы/наследование/полиморфизм

Таким образом та хрень, которую пытаются впихнуть в с++/жабе/с# и иже с ними не является естественной для людского мышления вещью.

Спасибо, кэп.

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

Тесты способны докуазать наличие ошибок, а не их отсутствие

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

Зато получишь NullPointerException

В динамическом языке ты равновероятно получишь как NoSuchProperty, так и NullPointerException. В жестко типизированном - только второй <сарказм>А в Objective-C можно просто отделаться NIL-ом</сарказм>

У меня тут проблема в том, что я не могу понять, что является фундаментом. Функция является объектом и захватывает/принимает другие объекты или объект состоит из методов(функций). Конкретно все упирается в этот самый <call>...

А хаскель, который нифига не объектный, вместо нулпойнтера ругнётся во время компиляции на тебя что у тебя функция определена не для любого элемента типа Maybe a.

Спольски ексель пилил, а не уиндоуз.

хрень не является естественной для людского мышления

Хрень-то да, довольно синтетическая. Загвоздка в том, чтобы приспособить и прогнуть ЯП под естественный способ мышления. Увы, но ничего удачнее чем ООП пока не придумали.

Увы, но ничего удачнее чем ООП пока не придумали.

Тут следует уточнить, что под ООП ты подразумеваешь не то, что остальное человечество. А так --- всё прекрасно.

Функция - это код + контекст, элементы которого функция может использовать тем или иным способом.

У какой-нибудь функции верхнего уровня контекст «процесс и environment»

У статического метода контекст это «процесс, environment и синглетон с глобальными членами классов»

У метода объекта контекст включает в себя «процесс, environment, синглетон с глобальными членами классов и атрибуты экземпляра объекта»

У какого-нибудь замыкания определенного внутри метода объекта контекст это «процесс, environment, синглетон с глобальными членами классов, атрибуты экземпляра объекта и [некоторые] локальные переменные определенные внутри метода».

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

Зато синтаксически удобно кидаться «объектами» которые суть контекст и список методов, и при вызове метода через экземпляр объекта, у тебя вызывается по сути обычная функция, для которой устанавливается соответствующий контекст.

Тут следует уточнить, что под ООП ты подразумеваешь не то, что остальное человечество.

Можешь за одно учесть, я разработчик на С++ с 10-летним стажем ;)

Да. И синдром утёнка тоже учтём.

Синдром утенка у меня к васику и ассемблеру должен быть, по идее. Я их в школе сожрал. Потом был Си. А кресты — начиная только с середины института...

Синдром утёнка проявляется не к первому увиденному объекту, а к первому --- обладающему определёнными свойствами.

обладающему определёнными свойствами

Какими?

Хорошая тема для кандидатской по психологии.

ты выборочно выбираешь на что отвечать. понимаю. удобнее отвечать мимо сути, когда по сути сказать нечего.

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

Зато синтаксически удобно кидаться «объектами» которые суть контекст и список методов

Так каждый из методов - тоже объект, со своими методами(по крайней мере <call>) и т.д. Так? Вот и спрашивается в задачнике, как так получается, что мы упираемся в рекурсивное определение <call>, который метод, а метод, соответственно объект с методом <call>... Я наверно хреново выражаю мысль...

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

Почему только от первого параметра?

https://ru.wikipedia.org/wiki/Мультиметод

чтобы необученные программисты или просто индусы не стреляли себе в ноги.

В интернете все крутые. На практике ошибаются все. Кто-то больше, кто-то меньше, но все же.

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

Зачем тебе тесты, ты же и так умный? Ведь тесты тоже для индусов.

Я про необходимое условие говорил. Обычные методы диспетчеризуются по первому аргументу, мультиметоды по всем.

Зачем тебе тесты, ты же и так умный? Ведь тесты тоже для индусов.

мне можно без тестов... :)

Отвечать на бред типа

жёсткость парадигм, которые нужны, чтобы необученные программисты или просто индусы не стреляли себе в ноги

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

Питон — пример языка, в котором функция, если копнуть, на самом деле объект. И внутри неё сидит __code__, который тоже объект, и в котором помимо всего прочего сидит co_code, который собственно содержит байткод для исполнения.

Убеждать фанатичных хейтеров сильной статической типизации в её полезности сравнимо с разгребанием снега во время метели.

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

Начни изучение истории появления ООП с предпосылок разработки и внедрения зыка Simula 67.

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

draw(circle) и draw(rectange) в одной программе

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

Ну да — вместо явного case по типу аргументов настоящее ООП оборачивает это в выбор средой исполнения правильного значения объекта из RTTI, по таблице виртуальных методов в рантайме ищет правильный вызов, делает его самостоятельно без участия программиста и называет такое поведение «полиморфизмом». Однако многие ООП-программисты всё равно используют case для определения типа объекта и что с ним делать. :))

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

Всё ещё хуже. У ООП есть две неразрешимые задачи

1. Кто кого взаимодействует. Теория относительности однако. screen.draw(rectangle) или rectangle.draw(screen) или вообще manager.draw(rectangle, screen). Решается полуинтуитивно. Если не угадал в какую сторону будет расширение надо переписывать почти всё. Спасает CLOS и похожие системы.

2. Что является классом, а что нет. Если что-то является классом, то класс объекта неизменен на время жизни объекта. Вот например: есть в программе эллипсы, которые можно рисовать и круги, которые отрисовываются другим цветом: можно ли отнаследовать круг от эллипса? Вроде да. А потом эллипсу добавляется метод масштабирования по осям. Круг при выполнении этого метода перестаёт быть кругом. Упс! Смена структуры с превращением отдельных эллипс и круг в единый тип — опять переписывать почти всё. Решается либо «классами» в стиле JS, либо CLOS. В них есть change-class.

Но CLOS не является ООП, так как в нём нет инкапсуляции. Разве что считать таковой неэкспортирование символа из пакета.

Длительный рефакторинг в сложной модели - плата за жесткую типизацию

В питоне рефакторить приходится столько же, если не больше. букв меньше, но проблема угадывания «правильной» структуры остаётся.

Вот например: есть в программе эллипсы, которые можно рисовать и круги, которые отрисовываются другим цветом: можно ли отнаследовать круг от эллипса? Вроде да. А потом эллипсу добавляется метод масштабирования по осям. Круг при выполнении этого метода перестаёт быть кругом. Упс! Смена структуры с превращением отдельных эллипс и круг в единый тип — опять переписывать почти всё.

Ага: «Слон — это бегемот с хоботом и большими ушами».

Одна из ключевых концепций ООП — наследование — распадается, а вместе с ней распадается и другая ключевая концепция — полиморфизм. Инкапсуляция, впрочем, остаётся.

У каждого свой подход.

я предпочитаю задачи решать не заморачиваясь всеми этими продумываниями. и, как ни странно, они решаются

Что-то как-то перлом и шеллом потянуло.