Что такое ООП

Увезить этого поехавшего!

Убейся. Твой пример - это ООП в упоротой степени.

Нет в ООП никаких сообщений. Я работал с Java, C#, C++, Python, и нет сообщений никаких - просто тела функций дергают функции, принадлежащие каким-то классам, подставляя нужный this в качестве первого аргумента при записи его через точку.

Так это потому, что никакого ООП не существует; коллективная галлюцинация.

Это относится к реализации. Нет разницы, как это реализовано, хоть через те же подстановки, хоть как то еще.

А вообще, полноценными сообщениями, конечно следует считать только такие, которые обрабатывает сам объект. То есть, лень на уровне реализации должна быть.

просто тела функций дергают функции

И «тела функций» сами по себе ничего не дергают. Это реализация твоего ЯП, грубо говоря, делает так, чтобы тебе казалось, что функции что то там дергают. На самом деле это просо куски, в которых реализация производит подстановки и редукции.

Sum.code = a + b

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

prog = new ProgramOnLanguageX
prog.code = "...."
prog.run

В этом смысле, разумеется, можно считать, что всё есть ООП.

Попробуй выразить в ООП

(define tree->generator
  (lambda (tree)
    (let ((caller '*))
      (letrec
          ((generate-leaves
            (lambda ()
              (let loop ((tree tree))
                (cond ((null? tree) 'skip)
                      ((pair? tree)
                       (loop (car tree))
                       (loop (cdr tree)))
                      (else
                       (call/cc
                        (lambda (rest-of-tree)
                          (set! generate-leaves
                            (lambda ()
                              (rest-of-tree 'resume)))
                          (caller tree))))))
              (caller '()))))
        (lambda ()
          (call/cc
           (lambda (k)
             (set! caller k)
             (generate-leaves))))))))

Или Haskell (если уж речь зашла за ФП):

instance C Int where
    f = (+1)
    g = (+)
    h x y = x
    i = head
    j x = x - 1
    new = 0

instance C Double where
    f x = if x > 5 then 2 else 3
    g x y = x - truncate y
    h x y = x + 1
    i = length
    j x = fromRational (toRational x) / 3
    new = 0.5

const1 = (new :: Double) + 2.0  -- должно быть 2.5

const2 = (new :: Int) - 2 -- должно быть -2

test1 x = f x + j x
--> test1 2
--4
--> test1 3
--6

test2 x = if x == 0.5 then g 2 x else g 1 x
--> test2 2
-- -1
--> test2 4
-- -3

дергают функции, принадлежащие каким-то классам

Ты же в коде не пишешь имя класса. Вот это определение функции по первому параметру и есть «отправка сообщения».

На самом деле это просо куски, в которых реализация производит подстановки и редукции.

Какую подстановку делает printLn(«Hello, World!») ?

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

ООП - это квадрат унаследованный от прямоугольника.

Какую подстановку делает printLn(«Hello, World!») ?

пример не совсем корректен, потому что printLn — тут имеется в виду нейтив. Если определить myPrintLn = function(arg){printLn(arg)}, то происходит именно это. При вызове myPrintLn("foo") интерпретатор распознает аппликацию, фактический аргумент подставляется на место формального, выражение редуцируется до primtLn("foo") и выполняется. То есть, тут не мифическое «тело» что то дергает, а именно исполнитель. Концептуально, то же самое происходит и с нейтив-вызовом, просто нет *чисто синтаксического представления* в языке.

ООП - это квадрат унаследованный от прямоугольника.

Наоборот, в ООП квадрат не является прямоугольником (нельзя наследовать, так как не выполняется принцип Лисков).

А если рассматривать данное выражение с точки зрения ООП, то у нас объект, условно назовем его Global, получает сообщение printLn(«Hello, world»), и он знает, как обработать данное сообщение. Как конкретно он его обрабатывает, нас не волнует, объект — это черный ящик.

выражение редуцируется до primtLn(«foo») и выполняется.

Ладно, до чего редуцируется

myReadPrintLn = function(arg){if read() = "ok" then printLn(arg) else printLn("bad input") }

read() — это ввод с клавиатуры.

в ООП квадрат не является прямоугольником (нельзя наследовать, так как не выполняется принцип Лисков).

А где там нарушается принцип Лисков?

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

Наоборот, в ООП квадрат не является прямоугольником (нельзя наследовать, так как не выполняется принцип Лисков).

Наоборот твоё наоборот, ты всё перепутал. Квадрат таки является прямоугольником по Лисков - частное наследуется от общего.

Ладно, до чего редуцируется

до

if read() = "ok" then printLn(realArg) else printLn("bad input")

Objects are poor man's closures.

А где там нарушается принцип Лисков?

http://citforum.ru/programming/digest/lspv/

Для Ъ:

void LSPV(Rectangle& r){
  r.SetWidth(5);
  r.SetHeight(4);
  assert(r.GetWidth() * r.GetHeight()) == 20);
}

if read() = «ok» then printLn(realArg) else printLn(«bad input»)

То есть отсюда следует, что функции «read» и «printLn» таки «дёргает» тело функции myReadPrintLn.

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

Потому что это уже будет не квадрат?

Наоборот, в ООП квадрат не является прямоугольником (нельзя наследовать, так как не выполняется принцип Лисков).

только если они мутабельные

Наоборот твоё наоборот, ты всё перепутал. Квадрат таки является прямоугольником по Лисков - частное наследуется от общего.

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

только если они мутабельные

Немутабельное ООП — это оксюморон. В том смысле, что объект в ООП подразумевает структуру данных с состоянием и методы для работы с этой структурой.

Как только мы отказываемся от состояния (значит нет ни одного поля, даже приватного), то ООП редуцируется до модулей (пространств имён).

Это все чушь, на самом деле.

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

Немутабельное ООП — это оксюморон

Это не оксюморон, это ФП, как часный случай ООП, как раз. Тот факт, даже, что объекты мутабельны, еще не означает, что их кто-то насильно заставляет менять.

ООП - зло, разрушающее неокрепшие умы. Иногда разбираем проекты, где психопаты лепят, например, 10-уровневое наследование классов.

ФП, как часный случай ООП

Нормальное ФП, где возможно

class C a where
    f :: a -> Int
    g :: Int -> a -> Int
    h :: Int -> (Int,a) -> Int
    i :: [a] -> Int
    j :: Int -> a
    new :: a

instance C Int where
    f = (+1)
    g = (+)
    h x y = x
    i = head
    j x = x - 1
    new = 0

instance C Double where
    f x = if x > 5 then 2 else 3
    g x y = x - truncate y
    h x y = x + 1
    i = length
    j x = fromRational (toRational x) / 3
    new = 0.5

ты в тесные рамки ООР не втиснешь. Так что, спорно, кто чей частный случай. ООП через ФП реализуется (через замыкания, например)

Ценой отказа от здравого смысла, и тотального кастрирования, и, как следствие — растягивания время разработки в сотни раз. Если отсутствие огня служит гарантией пожаробезопасности, должны ли мы отказаться от его использования? Может и должны, но только в частных случаях.

ты в тесные рамки ООР не втиснешь

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

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

через замыкания

Замыкания — это не часть ФП — прадигмы.

замыкания

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

Как только мы отказываемся от состояния (значит нет ни одного поля, даже приватного)

ты как-то резко перескочил от немутабельности к отсутствию полей

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

Определяем для типов Double и Int набор операций. g(x, y), например, раскрывается в x + y, если y — Int или в x - truncate y, если y — Double. Причём пользователь библиотеки может добавить этот набор операций к любому дополнительному типу.

Также должна работать унификация по типу: if x == 0.5 then g 2 x else g 1 x раскрывается в 1 - truncate x, так как из операции == следует, что типы x и 0.5 совпадают.

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

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

К тому же через замыкания полноценное ООП все равно не получится

Так есть же: CLOS, racket/class.

нет первоклассных окружений

В смысле?

либо реализовывать ООП поверх замыканий

Так я и говорю, что можно сделать ООП поверх замыканий. А ты «через замыкания полноценное ООП все равно не получится»

Вместо изменения ты можешь возвращать экземпляр с другими полями

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

Замыкания — это не часть ФП — прадигмы.

Хорошо, пусть будет лямбда-исчисление. В нём замыкания есть. Так вот: лямбда-исчисление с замыканиями продолжениями через ООП не выражается. А наоборот (ООП через замыкания) — тривиально.

В смысле?

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

with({a: 1}) window.foo = function(){doSomethingWith(a)}

Так я и говорю, что можно сделать ООП поверх замыканий

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

Хорошо, пусть будет лямбда-исчисление. В нём замыкания есть

Нет там замыканий. Не путай замыкания и лексическую область видимости. Как реализована эта лексическая область, лямбда-исчислению по-барабану (может через замыкания, а может и нет).

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

лямбда-исчисление с замыканиями продолжениями через ООП не выражается

У Карла Хьюитта есть бумага, где показано, как в модели Акторов(считай — то же ООП) реализуется LC буквально в пару строк. Так же есть доказательство того, что обратное невозможно. Если тебе это интересно, я могу найти эти бумаги.

Кстати, есть интересный факт. Язык Scheme изначально был ни чем иным, как (неудачной) попыткой реализовать модель Акторов с помощью некоего подобия расширенного лямбда-исчисления. ИЧСХ, авторы скрывают факт неудачи.

Почему такой, казалось бы простой вопрос не имеет однозначного ответа?

Потому что у тебя шизофрения.

продолжениями

Кстати, продолжений в LC тоже нет.

Определяем для типов Double и Int набор операций. g(x, y), например, раскрывается в x + y, если y — Int или в x - truncate y, если y — Double. Причём пользователь библиотеки может добавить этот набор операций к любому дополнительному типу.

Ну и почему это невозможно в ООП? Это всего лишь 2 класса с определенным набором опрераций. Добавление набора операций к другому типу реализуется тупо наследованием.

g(x, y), например, раскрывается в x + y, если y — Int или в x - truncate y, если y — Double

Тут даже оверхед. В ООП мы могли бы реализовать это на порядок изящней. Допустим так:

foo := Double with(1)
bar := Integer with(1)

foo g 1
bar g 2

Ну и почему это невозможно в ООП?

Потому что в ООП метод определяется первым аргументом. А в примере g (x, y) зависит от типа y.

У каждого из объектов свое собственное поле g

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

Или оттуда же функция h

h :: Int -> (Int,a) -> Int

a = Int => h x y = x
a = Double => h x y = x + 1

то есть

> h 2 (3, 4) 
2
> h 2 (3, 5.0) 
3