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

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

Управління залежністю є великою проблемою в ООП з наступних двох причин:

• Щільне з'єднання даних і коду.
• Повсюдне застосування побічних ефектів.

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

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

Розглянемо як приклад спамерську програму, яка скреблі веб-сторінки на адреси електронної пошти, а потім надсилає їх по електронній пошті. Якщо у вас є думка про DI, зараз ви думаєте про сервіси, які ви будете інкапсулювати за інтерфейсами, і які служби куди вводять. Я залишу цей дизайн як вправу для читача. Якщо у вас FP-мислення, зараз ви думаєте про входи та виходи для найнижчого рівня функцій, наприклад:

• Введіть адресу веб-сторінки, виведіть текст цієї сторінки.
• Введіть текст сторінки, виведіть список посилань на цій сторінці.
• Введіть текст сторінки, виведіть список адрес електронної пошти на цій сторінці.
• Введіть список адрес електронної пошти, виведіть список адрес електронної пошти із видаленими дублікатами.
• Введіть електронну адресу, виведіть спам для цієї адреси.
• Введіть спам-повідомлення, виведіть команди SMTP, щоб надіслати це повідомлення.

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

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

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

processText = spamToSMTP . emailAddressToSpam . removeEmailDups . textToEmailAddresses

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

processTextFancy = spamToSMTP . emailAddressToFancySpam . removeEmailDups . textToEmailAddresses

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

actuallyUsedProcessText = if (config == "Fancy") then processTextFancy else processText

Знову ж таки, не проблема, тому що всі залежності вказують в один бік. Нам не потрібно обертати деякі залежності, щоб усі вони вказували однаково, оскільки чисті функції вже змусили нас це робити.

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

чи функціональне програмування є життєздатною альтернативою моделям введення залежності?

Це вражає мене як дивне питання. Підходи до функціонального програмування значною мірою дотичні до введення залежності.

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

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

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

Швидка відповідь на ваше запитання: Ні .

Але, як стверджують інші, питання стосується двох, дещо не пов'язаних між собою понять.

Давайте зробимо це покроково.

DI призводить до нефункціонального стилю

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

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

const bookSeats = ( seatCount, getBookedSeatCount ) => { ... }

getBookedSeatCount(функція) може змінюватись, даючи різні результати для одного і того ж даного вводу. Це також робить bookSeatsнечистими.

Для цього є винятки - ви можете вводити один з двох алгоритмів сортування, які реалізують одне і те ж відображення вводу-виводу, хоча і використовуючи різні алгоритми. Але це винятки.

Система не може бути чистою

Те, що система не може бути чистою, однаково ігнорується, як це стверджується у джерелах функціонального програмування.

Система повинна мати побічні ефекти, очевидними прикладами є:

• UI
• База даних
• API (в архітектурі клієнт-сервер)

Тому частина вашої системи повинна включати побічні ефекти, і ця частина також може включати в себе імперативний стиль або стиль ОО.

Парадигма оболонки

Запозичивши умови з чудової розмови про Гері Бернхардта про межі , хороша архітектура системи (або модуля) включатиме ці два шари:

• Основні
  • Чисті функції
  • Відгалуження
  • Ніяких залежностей
• Оболонка
  • Нечисті (побічні ефекти)
  • Відсутні розгалуження
  • Залежності
  • Може бути імперативним, включати стиль ОО тощо.

Ключовим способом є "розщеплення" системи на чисту частину (серцевина) і нечисту частину (оболонку).

Незважаючи на те, що пропонує дефектне рішення (і висновок), ця стаття Марка Семана пропонує саме таку концепцію. Реалізація Haskell є особливо проникливою, оскільки показує, що все це можна зробити за допомогою FP.

DI та FP

Використовувати DI абсолютно розумно, навіть якщо основна частина вашої заявки є чистою. Ключовим моментом є обмеження DI в нечистій оболонці.

Прикладом можуть служити заглушки API - ви хочете справжній API у виробництві, але використовуйте заглушки в тестуванні. Тут дуже допоможе дотримання моделі оболонки.

Висновок

Тож FP і DI не є абсолютно альтернативою. Ви, ймовірно, маєте і те, і інше у своїй системі, і порада - забезпечити розділення між чистою та нечистою частиною системи, де FP та DI проживають відповідно.

З точки зору OOP функції можна вважати інтерфейсами однометодними.

Інтерфейс - сильніший контракт, ніж функція.

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

void DoStuff(Func<DateTime> getDateTime) {}; //Anything that satisfies the signature can be injected.

проти

void DoStuff(IDateTimeProvider dateTimeProvider) {}; //Only types implementing the interface can be injected.