Можете ли вы представить какой-либо другой способ реализации ОО, кроме классического подхода на основе классов?

Question

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

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

[EDIT]: Просто чтобы прояснить ситуацию. Как указано выше, я уже знаю программирование на основе прототипов.

Answer 1

Оформить Программирование на основе прототипов .

Answer 2

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

Эрланг использует нечто подобное, как мне сказали ... по крайней мере, похоже. Суть актерской модели в том, что ее не нужно реализовывать чисто, поэтому она не должна быть частью Erlang.

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

Answer 3

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

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

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

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

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

Answer 4

Я думаю, у вас возникли проблемы с определением "классического ОО" подхода. Является ли метод сигнала в Objective-C классическим или статическим в стандарте C ++?

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

(define (create-ball color)
    (lambda (attribute-name)
       (if (equal? attribute-name "color")
            color
            "method-not-supported"))))

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

Answer 5

Язык Google Go использует совершенно иной подход к ориентации объектов, возможно, стоит посмотреть.

Answer 6

Взгляните на CLOS, который в основном основан на функции / методе.

Answer 7

взгляните на javascript, который имеет модель на основе прототипа, или посмотрите lua, который имеет какой-то странный способ реализовать ориентацию объекта