Де всі схеми дизайну функціонального програмування? [зачинено]

Література з програмування OO рясна моделями дизайну. Більшість книг з об’єктно-орієнтованого програмування присвячують главу чи другу розробці моделей, таких як фабрики та декоратори. Отже, які еквівалентні зразки функціональних мов і чому ще ніхто не написав про них книгу? Чи є щось особливе у функціональних мовах, що заперечує потребу в моделях дизайну?

OO та функціональне програмування - це дві дуже різні парадигми програмування, а схеми проектування (DP) є важливою частиною проектування та програмування OO. DP не мають такої ролі у функціональному програмуванні.

Можна навіть сказати, що DP не потрібні у функціональному програмуванні - немає свербіння, від якого DP вилікується.

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

• Пітер Норвіг встановив, що 16 з 23 моделей у книзі " Шаблони дизайну " є " невидимими або простими г" у Ліспі чи Ділані.

• "Багато моделей передбачають орієнтацію на об'єкт або більш загальний стан, що змінюється, і тому можуть бути неприйнятними для функціональних мов програмування, в яких дані є незмінними або трактуються як такі". - http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29

Джеремі Гіббонс пише книгу. Поки це не закінчено, ви можете прочитати його блог « Шаблони у функціональному програмуванні» . Він рекомендує читати свої пости від найдавніших до найновіших.

Перегляньте і його публікації . Він охоплює банду з чотирьох моделей у шаблонах дизайну як загальноприйнятих програм типу вищих порядків та описує схеми програмування з рекурсивними рівняннями в програмуванні Орігамі (складки та розгортання).

Простий факт полягає в тому, що багато моделей OO вважатимуться ідіомами функціональних мов (особливо оригінальних моделей GoF). Наприклад, шаблон Iterator (вбудований до таких мов, як C # зараз) просто не потрібен у Lisp або ML, у яких є оператори послідовності.

Багато моделей, які ми використовуємо в системах OO, є для того, щоб допомогти нам вивести «несуттєві» речі, щоб ми могли зосередитись на об'єктах кодування. Іншими словами, шаблони - це рішення нецікавих частин програми. Ми повинні використовувати шаблони для вирішення загальних потреб, які були вирішені раніше (як, наприклад, шаблони в Fowlers Patterns of Enterprise Application Architecture для роботи з такими речами, як передача бази даних, або xUnit Patterns для підвищення рівня тестування вашого блоку), щоб ми могли зосередитись на додаванні вартості бізнесу. для застосування.

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

Гарна розмова (~ 45 хв) на цю тему Стюарт Сьєрра:

http://www.infoq.com/presentations/Clojure-Design-Patterns

Не обов'язково і авторитетно, але я визнав низку його прикладів із власного досвіду використання ФП для аналізу даних.

Приклади, написані Clojure, але, ймовірно, застосовні до будь-якої мови FP. Імена, які він надає шаблонам, які він охоплює:

• Стан / Подія
• Наслідки
• Акумулятор
• Зменшити / поєднати
• Рекурсивне розширення
• Трубопровід
• Обгортка
• Токен
• Спостерігач
• Стратегія

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

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

Після того, як ви покровите Haskell, вам вистачить арсеналу FP у вашому розпорядженні, щоб бути небезпечним. Справа в тому, тримайте його, поки не отримаєте. Немає ярликів.

Оскільки методологія проектування FP полягає у розробці типів, щоб точно відображати проблемний простір, а реалізація повинна слідувати автоматично, еквівалент FP книги про шаблони дизайну є чимось подібним до чисто функціональних структур даних Кріса Окасакі .