Передача функцій в інші функції як параметри, погана практика?

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

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

Це дає мені таке "погане почуття", коли я відчуваю, що це жахлива практика, і я можу придумати деякі причини, але я хочу певне підтвердження, перш ніж запропонувати переробляти систему. Мені було цікаво, чи має хто-небудь досвід з цією можливою проблемою?

Це не проблема.

Це відома методика. Це функції вищого порядку (функції, які приймають функції як параметри).

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

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

Вони не просто використовуються для функціонального програмування. Вони також можуть бути відомі як зворотні дзвінки :

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

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

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

Це не погано. Насправді це дуже гарна річ.

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

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

Технічно функція C ++ - це також тип об'єкта зворотного виклику, який використовує синтаксичний цукор operator()(), щоб зробити те ж саме.

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

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

Як вже було сказано, це не погана практика. Це просто спосіб розв’язування та розділення відповідальності. Наприклад, в OOP ви зробите щось подібне:

public void doSomethingGeneric(ISpecifier specifier) {
    //do generic stuff
    specifier.doSomethingSpecific();
    //do some other generic stuff
}

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

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

Однак є кілька можливих недоліків простих зворотних викликів:

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

З простими веб-сервісами добре працює, як ви це робите, але це стає незручно, якщо вам потрібно більш складні послідовності викликів. Однак є кілька альтернатив. Наприклад, у JavaScript відбувся перехід до використання обіцянок ( Що так чудово в обіцянках JavaScript ).

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