Що таке побічні ефекти програмування?
Кожного разу, коли ми говоримо про певні концепції програмування, я вважаю, що важливо відійти від того, що ми обговорюємо, і поглянути на речі в контексті більшої картини.
Деякі модулі вводять побічні ефекти; деякі ні. Це добре.
Наприклад, учора я коротко торкнувся ідеї програмування побічних ефектів, але я зробив це, коли говорив про використання PSR. І для тих, хто просто цікавиться аспектами програмування в більш загальному сенсі, також важливо їх розуміти.
Пам’ятайте, що ідея побічних ефектів , як зазначено в PSR-1, така:
Файл ПОВИНЕН декларувати нові символи (класи, функції, константи тощо) і не викликати жодних інших побічних ефектів, або СЛІД виконувати логіку з побічними ефектами, але НЕ ПОВИНЕН робити те й інше.
У цій публікації я не дуже зацікавлений в обговоренні логіки з побічними ефектами (оскільки бувають випадки, коли побічні ефекти трапляються). Натомість я більше стурбований розумінням побічних ефектів програмування (що це таке, чого слід уникати тощо).
Зрештою, говорити про побічні ефекти в одному контексті може означати одне, тоді як у програмуванні це може означати інше.
Програмування побічних ефектів
Отже, вся ідея або визначення загального побічного ефекту проста, чи не так?
вторинний, як правило, небажаний ефект препарату або лікування.
Вилучіть весь аспект лікування, і ви залишитеся з «вторинним, … небажаним ефектом». Гаразд, ось частина, яка може заплутати:
- ми вибираємо включити файл,
- ми знаємо, що робить файл,
- таким чином, якщо ми знаємо, що ми включаємо і що це робить, як це може представити щось небажане?
Принаймні, так я часто чую, коли йдеться про побічні ефекти. У програмуванні я завжди узагальнював побічні ефекти як будь-що, що змінює стан програми.
Досить легко, чи не так?
Побічні ефекти в WordPress
Тож припустімо, що ви працюєте з WordPress, оскільки це те, що я роблю та про що пишу 🙂, і у нас є файл, який відповідає за додавання пункту підменю до одного з існуючих меню верхнього рівня.
Цей клас може бути відносно простим у тому, що він обертає правильний виклик WordPress API, він запускається, коли приєднується до [належного] хука, а потім додає підменю, як і передбачено.
Але, скажімо, цей клас, метод у класі або включення файлу, що цей клас також додає деякі JavaScript або стилі, які змінюють стан пункту підменю таким чином, що він виділяється, він поводиться так, ніби його «клацнули» або він робить те, чого ні програма, ні користувач не бажають.
Це буде побічним ефектом, оскільки він змінює стан програми.
Що має робити модуль?
Сам цей клас повинен робити одне :
Принцип єдиної відповідальності — це принцип комп’ютерного програмування, який стверджує, що кожен модуль або клас повинен нести відповідальність за окрему частину функціональних можливостей, наданих програмним забезпеченням, і ця відповідальність повинна бути повністю інкапсульована класом.
Але коли ми представляємо щось, що доповнює те, що він повинен робити – коли ми додаємо до його відповідальності або змінюємо єдине ядро, що він робить – тоді ми представляємо побічний ефект.
Пам’ятайте, що за своєю суттю це непогано (згідно з визначенням PSR-1 вище), але важливо розпізнавати, коли ми це робимо, а коли ні.
Отже, як нам додати функціональність?
Я думаю, що виникає природне запитання: якщо ми хочемо додати функціональність до програми, яка змінює її стан, як це зробити (і чи це неправильно)?
По-перше, ні, це не так. Я маю на увазі, що програми мають різні стани на основі різноманітних речей, чи не так? Іноді це трапляється, коли щось записується на диск або в базу даних; іноді це трапляється, коли користувач клацає елемент інтерфейсу і так далі.
Але як ці стани відбуваються, де природа побічних ефектів вступає в гру.
Візьмемо, наприклад, ідею підменю. Це має робити одну річ. Це не повинно змінювати нічого, крім того, що ми бачимо на екрані.
- Він не повинен писати в базу даних,
- Він не повинен налаштовувати прослуховувач подій, коли інший об’єкт додає підменю,
- Він не повинен змінювати подання нічого поза собою.
- І так далі.
Додавання функціональності працює так само: ви вводите класи, які відповідають за виконання конкретної речі, і дозволяєте їм це робити. Коли ці компоненти працюють у поєднанні один з одним, у вас є функціональна програма, у якій кожен модуль (клас/функція/що завгодно) залишається на своїй смузі, так би мовити.
Що таке емпіричне правило?
Я впевнений, що багато хто з вас, хто читає це, знають, що таке побічні ефекти, а що ні. І я, як і ти, маю свій.
Подумайте про це так:
Якщо ви викликаєте метод, і він повертає значення, а потім знову викликаєте метод із тим самим набором даних, він має повернути те саме значення.
Таким чином ви знаєте, що ваша функція, клас або загальний модуль не має побічних ефектів.
І, як у будь-якій іншій справі, я робив ці помилки (і, ймовірно, буду продовжувати), але це питання спробувати покращитися, не роблячи цього.
Згодом це стане новою нормою.