Функціональне програмування проти об'єктно-орієнтованого програмування [закрито]

Я до цього часу в основному зазнавав програми програмування OO і з нетерпінням чекаю вивчення функціональної мови. Мої запитання:

• Коли ви вибираєте функціональне програмування над об'єктно-орієнтованим?
• Які типові визначення проблеми, коли функціональне програмування є кращим вибором?

Коли ви вибираєте функціональне програмування на об'єктно-орієнтованому?

Коли ви передбачите розвиток еволюції програмного забезпечення:

• Об'єктно-орієнтовані мови хороші, коли у вас є фіксований набір операцій над речами , і коли ваш код розвивається, ви в першу чергу додаєте нові речі. Це можна досягти, додавши нові класи, які реалізують існуючі методи, а існуючі класи залишаються в спокої.

• Функціональні мови хороші, коли у вас є фіксований набір речей , і коли ваш код розвивається, ви в першу чергу додаєте нові операції над існуючими речами. Це можна досягти, додавши нові функції, які обчислюють існуючі типи даних, а існуючі функції залишити в спокої.

Коли еволюція йде не так, у вас виникають проблеми:

• Додавання нової операції до об'єктно-орієнтованої програми може потребувати редагування багатьох визначень класів, щоб додати новий метод.

• Додавання нового виду до функціональної програми може потребувати редагування багатьох визначень функцій, щоб додати новий випадок.

Ця проблема добре відома вже багато років; У 1998 році Філ Вадлер назвав це "проблемою вираження" . Хоча деякі дослідники вважають, що проблему вираження можна вирішити за допомогою таких мовних особливостей, як міксин, загальновизнане рішення поки що не вплине на мейнстрім.

Які типові визначення проблеми, коли функціональне програмування є кращим вибором?

Функціональні мови досконалі в маніпулюванні символічними даними у вигляді дерева. Улюблений приклад - компілятори, де вихідні та проміжні мови змінюються рідко (переважно одні й ті ж речі ), але автори компіляторів завжди додають нові переклади та вдосконалення чи оптимізацію коду (нові операції над речами). Компіляція та переклад загалом - це "вбивчі програми" для функціональних мов.

Не обов’язково вибирати між двома парадигмами. Ви можете писати програмне забезпечення з архітектурою ОО, використовуючи багато функціональних понять. FP і OOP мають ортогональний характер .

Візьмемо для прикладу C #. Можна сказати, що це переважно OOP, але існує багато концепцій та конструкцій ПП. Якщо розглядати Linq , найважливіші конструкції, які дозволяють Linq існувати, мають функціональний характер: лямбда-вирази .

Інший приклад, F #. Можна сказати, що це здебільшого FP, але є багато концепцій та конструкцій OOP. Ви можете визначити класи, абстрактні класи, інтерфейси, мати справу зі спадщиною. Ви навіть можете користуватися мутабельністю, коли це робить ваш код більш чітким або коли він різко підвищує продуктивність.

Багато сучасних мов є багатопарадигмою.

Рекомендовані читання

Оскільки я перебуваю в одному човні (фон OOP, навчання FP), я б запропонував вам кілька читань, які я дуже оцінив:

• Функціональне програмування для щоденної розробки .NET , Джеремі Міллер. Чудова стаття (хоча і не форматована), що показує багато прийомів та практичних реальних прикладів FP на C #.

• Функціональне програмування в реальному світі , Томаш Петрикек. Чудова книга, яка займається переважно концепціями ПП, намагаючись пояснити, що вони є, коли їх слід використовувати. Прикладів є і в F #, і в C #. Також блог Петричека є чудовим джерелом інформації.

Об'єктно-орієнтоване програмування пропонує:

1. Інкапсуляція, до
   • контрольна мутація внутрішнього стану
   • обмеження зв'язку внутрішнього представництва
2. Підгрупування, що дозволяє:
   • заміна сумісних типів (поліморфізм)
   • сирий спосіб розподілу реалізації між класами (успадкування реалізації)

Функціональне програмування в Haskell або навіть у Scala може дозволити заміщення через більш загальний механізм класів типів. Внутрішній стан, що змінюється, або знешкоджується, або забороняється. Також може бути досягнута інкапсуляція внутрішнього представництва. Дивіться Haskell vs OOP для хорошого порівняння.

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

EDITED Видалено посилання на неявні перетворення під час обговорення класів типів. У Scala класи типів кодуються неявними параметрами, а не перетвореннями, хоча неявні перетворення є ще одним засобом досягнення заміни сумісних типів.

1. Якщо ви перебуваєте в сильно одночасному середовищі, тоді корисне чисте функціональне програмування. Відсутність змінного стану робить паралельність майже тривіальною. Дивіться Ерланг.

2. У мові мультипарадигми ви можете захотіти моделювати деякі функції функціонально, якщо існування змінного стану є детальною частиною реалізації, і, таким чином, FP є хорошою моделлю для проблемної області. Наприклад, див. Розуміння списку на Python або std.range у мові програмування D. Вони натхненні функціональним програмуванням.