Подтвердить что ты не робот

Являются ли FP и OO ортогональными?

Я слышал это снова и снова, и я пытаюсь понять и утвердить идею о том, что FP и OO ортогональны.

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

FP поощряет неизменность и чистоту как можно больше, в то время как OO кажется построенным для состояния и мутации - слегка организованной версии императивного программирования? Я понимаю, что объекты могут быть неизменными, но OO, по-видимому, подразумевает состояние/изменение для меня.

Они кажутся противоположностями. Как это влияет на их ортогональность?

Язык, подобный Scala, упрощает выполнение OO и FP, влияет ли это на ортогональность двух методов?

4b9b3361

Ответ 1

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

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

Однако объектно-ориентированное программирование охватывает такие темы, как:

  • Герметизация
  • Полиморфизм
  • Абстракция

Ничто из этого не подразумевает изменчивость, и ничто из этого не исключает функционального программирования. Так что да, они ортогональны в том, что они разные концепции. Они не противоположности - вы можете использовать один или другой или оба (или даже ни одного). Такие языки, как Scala и F #, пытаются объединить обе парадигмы в один язык:

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

Источник

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

Источник

Ответ 2

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

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

Они кажутся противоположностями. Как это влияет на их ортогональность?

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

и OO кажется чем-то, что создано для состояния и мутации (слегка организованная версия императивного программирования?). И я понимаю, что объекты могут быть неизменными. Но ОО, кажется, подразумевает состояние/изменение для меня.

Хотя это верно для большинства основных языков OO, нет причин, по которым язык OO должен иметь изменяемое состояние.

Если язык имеет объекты, методы, виртуальное наследование и ad-hoc-полиморфизм, это объектно-ориентированный язык - независимо от того, имеет ли он изменяемое состояние или нет.

Ответ 3

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

Это означает, что два понятия не имеют противоположных идей или несовместимы друг с другом.

FP поощряет неизменность и чистоту как можно больше. и OO кажется чем-то, что построено для состояния и мутации (слегка организованная версия императивного программирования?). И я понимаю, что объекты могут быть неизменными. Но ОО, кажется, подразумевает состояние/изменение для меня.

Они кажутся противоположностями. Как это влияет на их ортогональность?

Язык, подобный Scala, упрощает выполнение OO и FP, влияет ли это на ортогональность двух методов?

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

В своем Scala Experiment поговорить в Google, Мартин Одерски очень хорошо объясняет, как он считает, что две концепции - OO и FP - ортогональны друг другу и как Scala элегантно и плавно объединяет две парадигмы в новую парадигму, известную в сообществе Scala как объектно-функциональную парадигму. Должен следить за разговорами.: -)


Другие примеры функционально-функциональных языков: OCaml, F #, Nemerle.

Ответ 4

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

Применяется к оригинальному вопросу, это означает, что существуют чисто функциональные, не объектно-ориентированные программные lanuages, такие как Haskell, чисто объектно-ориентированные "нефункциональные" языки, такие как Eiffel, но также и языки, которые не являются такими, как C и языки, такие как Scala.

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

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

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

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

Ответ 5

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

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

Например, функциональный язык, такой как OCaml, выполняет инкапсуляцию посредством лексического охвата и закрытия, тогда как объектно-ориентированные языки используют модификаторы public/private access. Они не являются несовместимыми механизмами per se, но они избыточны, а язык, такой как F # (в основном функциональный язык, который стремится жить в гармонии с объектно-ориентированной библиотекой .NET и языковым стеком), должен идти в длину до моста разрыв.

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

Ответ 6

Идея объектов может быть реализована неизменно. Примером может служить книга "" Теория объектов", написанная Абади и Карделли, которая направлена ​​на формализацию этих идей и где объекты сначала заданы неизменяемыми семантики, потому что это упрощает рассуждение об объектно-ориентированных программах.

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

Ответ 7

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

FP поощряет неизменность и чистоту как можно больше

Вы говорите о чисто функциональном программировании.

в то время как OO кажется построенным для состояния и мутации

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

Язык, подобный Scala, упрощает выполнение OO и FP как

Не совсем. Отсутствие оптимизации хвостового вызова означает, что большинство идиоматического чисто функционального кода будет переполнять поток в Scala, потому что он пропускает стековые фреймы. Например, стиль продолжения прохождения (CPS) и все методы, описанные в статье Это о том, чтобы обернуть его Брюсом МакАдамом. Нет простого способа исправить это, потому что сам JVM неспособен к оптимизации хвостового вызова.

Что касается ортогональности чисто функционального программирования и объектно-ориентированного программирования, я бы сказал, что они по крайней мере близки к ортогональным просто потому, что чисто функциональное программирование имеет дело только с программами в малых (например, функциями более высокого порядка), тогда как объектно-ориентированное программирование с крупномасштабным структурированием программ. Именно поэтому функциональные языки программирования обычно предоставляют некоторый другой механизм для крупномасштабного структурирования, например. модульные системы высшего порядка Standard ML и OCaml или CLOS для Common Lisp или типы для Haskell.

Ответ 8

Одна вещь, которая помогла мне понять взаимосвязь между FP и OO, была книга SICP, в частности раздел "Модульность функциональных программ и модульность объектов" Если вы подумываете об этих проблемах, и у вас есть свободные выходные, возможно, стоит прочитать первые три главы, их красивые глаза.

Ответ 9

Я только что нашел замечательное объяснение ортогональности ООП и FP.

Основная идея заключается в следующем. Представьте, что мы работаем с АСТами математических выражений. Таким образом, у нас есть разные типы существительных (константа, сложение, умножение) и разные глаголы (eval, toString).

Скажем, выражение (1 + 2) * 3. Тогда AST будет:

       multiplication
         /        \
     addition      3
      /    \
     1      2

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

                +---------------------+-------------------------------------+
                | eval                | toString                            |
+---------------+---------------------+-------------------------------------+
| constant      | value               | value.toString                      |
+---------------+---------------------+-------------------------------------+
| addition      | lhs.eval + rhs.eval | lhs.toString + " + " + rhs.toString |
+---------------+---------------------+-------------------------------------+
| mutiplication | lhs.eval * rhs.eval | lhs.toString + " * " + rhs.toString |
+---------------+---------------------+-------------------------------------+

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

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

Ответ 10

ортогональным. Звучит неплохо. Если у вас есть образование, вы можете немного обмануть его и притвориться. Это немного похоже на парадигму.

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

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

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

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