Смущенный. Является ли ОО по своей сути императивным или это мультипарадигма?

Question

Когда я прочитал ответы и вопросы на stackoverflow, у меня сложилось впечатление, что ОО разделен на неотъемлемый императив.

Но не является ли ОО просто способом разделения кода и данных на объекты реального мира?

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

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

Или я что-то упустил?

Answer 1

Нет . ОО и императив - это две ортогональные концепции.

Например:

• Common Lisp Object System является примером Lisp OO и, возможно, самой сложной объектной системой.
• OCaml - это функциональный язык с объектной системой и модульной системой, поддерживающей объектно-ориентированную организацию
• Scala - это функциональный язык с очень гибкой ОО-системой
• Haskell позволяет писать объектно-ориентированный код, используя полиморфизм с более высоким родом

Есть много разных способов быть объектно-ориентированными.

Answer 2

Большинство ОО-языков являются обязательными, но вы можете использовать их в несколько функциональном стиле. Некоторые функциональные языки располагаются поверх OO-фреймворков (F # на .NET - наиболее очевидный пример), торгуя с некоторой «чистотой», чтобы заставить массивный фреймворк использовать там, где это необходимо.

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

Answer 3

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

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

Answer 4

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

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

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

Примером декларативного языка может быть Prolog, примером императивного языка может быть Fortran (и Настоящий программист может писать программы на языке FORTRAN на любом языке ).

В качестве примера кода, который является императивным и декларативным одновременно, рассмотрим эту реализацию последовательности Фибоначчи в Perl6:

my @fibonacci-sequence := 0, 1, * + * ... *;

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

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

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

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

Некоторые языки чисты, что означает, что все вычисления соответствуют парадигме. Например, Haskell - это чисто функциональный язык, а Smalltalk - это чисто объектно-ориентированный язык.

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

Answer 5

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

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

Answer 6

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

Я бы охарактеризовал сущность ООП с помощью объектов с поведением .

Википедия характеризует Объекты следующими тремя свойствами:

1. Идентичность : свойство объекта, которое отличает его от других объектов
2. Состояние : описывает данные, хранящиеся в объекте
3. Поведение : описывает методы в интерфейсе объекта, с помощью которых можно использовать объект

Многие объектно-ориентированные языки имеют концепцию классов, но на самом деле существуют также основанные на прототипах языки , подобные JavaScript.

Функциональные языки также могут использовать классы (например, классы типов в Haskell). Но только то, что у них есть классы, не означает, что они объектно-ориентированы или позволяют объектно-ориентированное программирование. Чтобы остаться на примере Haskell: у вас даже нет объектов! Нет такого понятия, как «идентичность»! Все, что вы можете сделать, это составить чистые функции!

То, что кто-то использует термин «классы», не означает, что он занимается объектно-ориентированным программированием!

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

Итак Да , императивное программирование присуще ООП.

Answer 7

Некоторые люди не согласны с тем, что ОО является императивной концепцией, поэтому вот мои рассуждения.

Основы объектной ориентации:

1. объекты хранят состояние (т.е. ссылки на другие объекты)
2. объекты получают (и обрабатывают) сообщения
3. обработка сообщения может привести к
   • сообщения отправляются на сам объект или другие объекты
   • изменение состояния объекта

Это означает, что oo-программирование требует изменяемого состояния , удерживаемого объектом (!) . Если вы моделируете изменение состояния, создавая серию объектов, вы нарушаете эти инварианты, просто так.

Flamebait: Если вы не согласны с этим определением объектной ориентации, обсудите это с Аланом Кей.