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