Объектно-ориентированное программирование и функциональное программирование?

Question

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

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

Мой вопрос в том, что, поскольку ОО может использовать состояние без состояния, а объекты не требуют состояния, это ООПэффективно расширенный набор FP?Есть ли какие-либо дополнительные преимущества / особенности FP, которые делают многопоточность более практичной, чем в ООП?

Answer 1

Это вопрос степени.

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

Хорошая аналогия с ОО в Си. Бывают моменты, когда ваши ограничения таковы, что C является правильным выбором, а OO-структура также является правильным выбором. GTK является хорошим примером этого. Очень сложно написать инструментарий пользовательского интерфейса без ООП. Однако это означает, что вы беретесь за работу, которая обычно выполняется компилятором. Некоторые вещи, которые просты на одном языке, становятся трудными или невозможными в языке без синтаксической и семантической поддержки. Например, я никогда не видел проект C, который эмулировал множественное наследование. Это просто слишком много ручного труда.

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

Что касается того, является ли ООП надмножеством FP, я даже не думаю, что эта концепция имеет смысл. С точки зрения выражения программ они оба полностью способны. Вы можете реализовать ОО-язык на языке FP и наоборот. Иногда один ближе к проблемной области, иногда другой. Несмотря на это, я думаю, что ваш реальный вопрос заключается в том, должен ли человек любить ФП, и ответ на этот вопрос - нет; используйте то, что вам нравится.

Я думаю, вам следует также рассмотреть возможность проверить модель Actor, потому что она более подходящая OO, а не недружественная к состоянию (просто совместно используемая состояние-недружественная), но все же приносящая преимущества масштабируемости / параллелизма.

Answer 2

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

Я думаю, это похоже на то, как программист на Си говорит, что, поскольку методы С можно объединить в структуру и заменить, не делает ли это надмножество ОО? Фактически, именно так C ++ изначально был реализован, но это не делает C языком OO.

Answer 3

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