Что такое side effect
side effect
1 side effect
2 side effect
3 side effect
побочный эффект
Изменение значений параметров или глобальных переменных при выполнении процедуры-функции.
[ ГОСТ 28397-89]
Тематики
Изменение значений параметров или глобальных переменных при выполнении процедуры-функции
4 side effect
5 side effect
6 side effect
7 side effect
8 side-effect
9 side effect
10 side effect
11 side-effect
12 side effect
13 side effect
14 side effect
15 side effect
16 side-effect
17 side effect
18 side effect
19 side effect
20 side effect
См. также в других словарях:
Side effect — can mean:* Adverse drug reaction, an unintended consequence specifically arising from drug therapy * Therapeutic effect, an unintended but desirable consequence of any kind of medical treatment * Adverse effect (medicine), an unintended, and… … Wikipedia
Side Effect — were an influential Disco band that recorded between 1972 and 1995. The group formed in Los Angeles in May 1972, when they started out as an all male trio and consisted of Louis Patton, Gregory Matta and leader Augie Johnson. [http://www.allmusic … Wikipedia
side-effect — side effects also side effect 1) N COUNT: usu pl The side effects of a drug are the effects, usually bad ones, that the drug has on you in addition to its function of curing illness or pain. The treatment has a whole host of extremely unpleasant… … English dictionary
side effect — side ef.fect n 1.) an effect that a drug has on your body in addition to curing pain or illness harmful/serious/adverse etc side effect ▪ a natural remedy with no harmful side effects side effect of ▪ the side effects of the medication 2.) an… … Dictionary of contemporary English
side effect — 1884, from SIDE (Cf. side) (adj.) + EFFECT (Cf. effect) (n.). Medical use, with reference to medicines, is recorded from 1939 … Etymology dictionary
side effect — side ef,fect noun count * 1. ) an effect of a medicine that is not intended and could be unpleasant: The treatment has no significant side effects. side effect of: the possible serious side effects of this drug 2. ) any additional result that you … Usage of the words and phrases in modern English
side effect — side′ effect n. an often adverse effect, as of a drug, that is secondary to the primary effect Also called side′ reac tion. Etymology: 1880–85 … From formal English to slang
side effect — ► NOUN ▪ a secondary, typically undesirable effect of a drug or medical treatment … English terms dictionary
Side Effect — [engl.], Nebenwirkung … Universal-Lexikon
side effect — noun ADJECTIVE ▪ common ▪ possible, potential ▪ adverse, bad, dangerous, debilitating, deleterious (esp. AmE) … Collocations dictionary
side effect — A result of drug or other therapy in addition to or in extension of the desired therapeutic effect; usually but not necessarily, connoting an undesirable effect. Although technically the therapeutic effect carried beyond the desired limit ( e.g … Medical dictionary
Чистые функции — JS: Функции
Функции в программировании обладают рядом важных характеристик. Зная их, мы можем точнее определять, как лучше разбивать код на функции и когда вообще их стоит выделять.
Детерминированность
Встроенная в JavaScript функция Math.random() возвращает случайное число от 0 до 1:
Функция нужная и полезная, но неудобная в отладке и тестировании. Это связано с тем, что для одних и тех же входных аргументов (отсутствие аргументов также попадает под это понятие), она может возвращать разные значения. Функции с таким поведением называются недетерминированными.
Например, недетерминированными являются функции, оперирующие системным временем. Так, функция Date.now() каждый раз возвращает новое значение:
Хотя прямо сейчас повторный запуск вернёт точно такое же значение, через год оно уже будет другим. То есть функция считается недетерминированной, если она ведёт себя так хотя бы единожды.
Детерминированные функции, напротив, ведут себя предсказуемо. Для одних и тех же входных данных они всегда выдают один и тот же результат. Именно такими являются функции в математике.
Функция становится недетерминированной и в том случае, если она обращается не только к своим аргументам, но и некоторым внешним данным, например глобальным переменным, переменным окружения и так далее. Так происходит потому, что внешние данные могут измениться, и функция начнёт выдавать другой результат, даже если в неё передаются одни и те же аргументы.
В общем случае нельзя сказать, что отсутствие детерминированности — абсолютное зло. Для работы многих программ и сайтов нужна функция, возвращающая случайное число или вычисляющая текущую дату. С другой стороны, в нашей власти разделить код так, чтобы в нем было как можно больше детерминированных частей. Общая рекомендация при работе с детерминированностью звучит следующим образом: если есть возможность написать функцию так, что она будет детерминированной, то так и делайте. Не используйте глобальных переменных, создавайте функции, зависящие только от своих собственных аргументов.
Понятие «Детерминированность» не ограничивается программированием или математикой. Сквозь него можно рассматривать практически любой процесс. Например, подбрасывание монетки — недетерминированный процесс, его результат случаен.
Побочные эффекты (side effects)
Вторая ключевая характеристика функций — наличие побочных эффектов. Побочными эффектами называют любые взаимодействия с внешней средой. К ним относятся файловые операции, такие как запись в файл, чтение файла, отправка или приём данных по сети и даже вывод в консоль.
Кроме того, побочными эффектами считаются изменения внешних переменных (например, глобальных) и входных параметров в случае, когда они передаются по ссылке.
А вот вычисления (логика), напротив, не содержат побочных эффектов. Например, функция, суммирующая два переданных аргументами числа.
Побочные эффекты составляют одну из самых больших сложностей при разработке. Их наличие значительно затрудняет логику кода и тестирование. Приводит к возникновению огромного числа ошибок. Только при работе с файлами количество возможных ошибок измеряется сотней: начиная с того, что закончилось место на диске, заканчивая попыткой читать данные из несуществующего файла. Для их предотвращения код обрастает большим числом проверок и защитных механизмов.
Без побочных эффектов невозможно написать ни одной полезной программы. Какие бы важные вычисления она ни делала, их результат должен быть как-то продемонстрирован. В самом простом случае его нужно вывести на экран, что автоматически приводит нас к побочным эффектам:
В реальных же приложениях, обычно, все сводится к взаимодействию с базой данных или отправкой запросов по сети.
Не существует способа избавиться от побочных эффектов совсем, но их влияние на программу можно минимизировать. Как правило, в типичной программе побочных эффектов не так много по отношению к остальному коду, и происходят они лишь в самом начале и в конце. Например, программа, которая конвертирует файл из текстового формата в PDF, в идеале выполняет ровно два побочных эффекта:
Между этими двумя пунктами и происходит основная работа, которая содержит чистую алгоритмическую часть. Побочные эффекты, в таком случае, будут находиться только в верхнем слое приложения, а ядро, выполняющее основную работу, останется чистым от них.
Инкремент и декремент — единственные базовые арифметические операции в JS, которые обладают побочными эффектами (изменяют само значение в переменной). Именно поэтому с ними сложно работать в составных выражениях. Они могут приводить к таким сложноотлавливаемым ошибкам, что во многих языках вообще отказались от их введения (в Ruby и Python их нет). В JS стандарты кодирования предписывают их не использовать.
Чистые функции
Идеальная функция с точки зрения удобства работы с ней называется чистой (pure). Чистая функция — это детерминированная функция, которая не производит побочных эффектов. Такая функция зависит только от своих входных аргументов и всегда ведёт себя предсказуемо.
Чистые функции обладают рядом ключевых достоинств:
Открыть доступ
Курсы программирования для новичков и опытных разработчиков. Начните обучение бесплатно.
Осторожно! Возможны побочные эффекты
Ежемесячная рассылка CSSSR
Новости, свежие статьи и многое другое
Поделиться
Начинать нужно с того, что сеет сомнение.
Типичный фронтенд
Давайте посмотрим на простой пример фронтенд-кода:
Что является результатом работы этой функции?
От чего зависит эта функция?
Теперь давайте скроем реализацию функции и ещё раз посмотрим на неё:
Хм, теперь кажется, что функция ни от чего не зависит и вообще ничего не делает. В целом всё логично — не видя реализации функции, мы не можем определить её действие. Давайте посмотрим на другую функцию:
И скроем её реализацию:
Два вида функций
sum берёт зависимые значения только из списка аргументов и возвращает результат только при помощи оператора return — то есть взаимодействует с окружающим кодом только через стандартные механизмы вызова функции.
Такие функции называются чистыми (pure).
app же, наоборот, в качестве аргументов использует данные, которые попадают в неё неявно (не через список аргументов), и возвращает результат своей работы неявно (не через return ).
Про такие функции говорят, что они обладают сайд-эффектами, и в противоположность чистым функциям их называют грязными.
Cайд-эффектами называют неявные зависимости функции или неявные результаты её работы.
Звучит довольно просто, однако на практике в языках без явных ограничений на чистоту функции данное определение предстаёт не таким однозначным.
Сайд-эффект — что ты такое?
Первое и самое главное:
Сайд-эффект — это не первоклассный объект
Что это значит? Первоклассный объект (first-class object) — это сущность в языке программирования, которую:
Проще говоря, первоклассный объект можно легко представить в виде некоторого значения. Очевидно, что для сайд-эффектов это не так. Мы не можем просто взять и переписать функцию app в виде:
Сайд-эффекты зависят от/влияют на внешнее окружение
Это довольно очевидное свойство. Для того, чтобы корректно выполнить некоторый сайд-эффект, нам необходимо корректное окружение: для HTTP запроса нужна рабочая сеть, для запроса к DOM необходим сформированный DOM и так далее.
Сайд-эффекты лишают функции ссылочной прозрачности
Ссылочная прозрачность (referential transparency) — свойство функции, благодаря которому можно всегда и везде вместо результата работы функции подставить её вызов.
Функции с сайд-эффектами не обладают этим свойством — вызвав app два раза, мы получим совершенно другие результаты (будет два listener вместо одного, два HTTP запроса при клике вместо одного и так далее).
Сайд-эффекты изменяют свойства кода, в котором используются, до самой вершины стека вызовов
На самом деле, скорее всего, последние два свойства вытекают из первого — но это только догадка, и поэтому я решил вынести их в отдельные пункты.
Что всё это значит для нас?
Ну, окей, сайд-эффекты имеют какие-то свои специфичные свойства. Но что эти свойства означают для нас на практике?
Код с сайд-эффектами сложен для анализа (как человеком, так и машиной)
Для начала давайте посмотрим на код без сайд-эффектов — все функции в нём чистые.
Мы можем легко увидеть, какие значения от каких зависят, а какие не играют роли. К примеру, мы видим, что от a ничего не зависит и его вычисление можно смело удалить.
Более того, мы можем построить граф вычислений:
А теперь попробуем проделать то же самое с кодом, в котором, возможно, содержатся сайд-эффекты:
Это оказывает влияние на:
Также в случае кода с сайд-эффектами значительно усложняется рефакторинг. К примеру, удаление не использующегося кода:
Код с сайд-эффектами сложно переиспользовать
Это менее очевидное следствие из свойств сайд-эффектов. Давайте вновь взглянем на код, состоящий из чистых функций.
Мы написали функцию, которая считает длину и сумму массива:
Используя её, мы можем легко написать функцию, вычисляющую только длину списка:
Чистые функции крайне легко переиспользуются: даже если они делают что-то лишнее или что-то немного не так, мы всегда можем исправить это, просто добавив обёртку из ещё одной чистой функции.
Любую проблему можно решить путём введения дополнительного уровня абстракции, кроме проблемы слишком большого количества уровней абстракции.
Давайте посмотрим на функцию с сайд-эффектами, которая делает HTTP запрос и записывает результат в некий файл:
Теперь где-то в коде нам понадобилось отправлять тот же запрос, но не записывать его в файл.
Cкорее всего, мы добавим специальную опцию в sendRequestAndWriteFile :
То же самое для ситуации, когда нам захотелось отправлять запросы на другой URL:
Это заставляет нас вместо простого переиспользования добавлять множество опций в функцию, что очень сильно увеличивает цикломатическую сложность кода a.k.a complexity.
Количество вариантов выполнения растёт со скоростью 2^n: для функции всего с двумя булевыми опциями мы получаем уже 4 варианта исполнения, для трёх опций — уже 8 и так далее.
Cайд-эффекты сложно тестировать
С этим наверняка знакомы все. Сравните:
Выглядит немного сложнее, да? Но постойте, мы не проверили тот факт, что наша функция делает ровно один HTTP запрос. Исправим:
Зачем мы вообще пишем автоматизированные тесты? Для того, чтобы контролировать изменения кодовой базы. В случае изменения поведения кода мы сразу увидим, что старые тесты не пройдут. Дело в том, что при достаточно большой кодовой базе различные изменения могут конфликтовать между собой и «ломать» друг друга. Автоматические тесты защищают наши изменения от случайной поломки при каких-либо правках (это может быть банальный мерж конфликтов).
Давайте изменим тестируемые функции и посмотрим, что произойдёт в обоих случаях:
Тест, конечно же, упадёт — 4 не равно
Теперь давайте изменим remoteAdd :
Результат работы функции изменился — теперь она ещё и пишет в файл. Однако наш тест совершенно этого не заметил и продолжает проходить как ни в чём не бывало.
Так как функции с сайд-эффектами зависят от внешнего мира и влияют на него неявно, то, соответственно, чтобы корректно протестировать такую функцию, необходимо:
Очевидно, что сделать это полностью корректно, скорее всего, невозможно, так как количество типов сайд-эффектов в JS не ограничено.
Какие проблемы у подобного подхода:
Если бы мы хотели протестировать код с сайд-эффектами «честно», мы должны были написать что-то подобное:
Альтернативным способом решения проблемы является написание полностью интеграционных тестов с полноценным браузерным или серверным окружением. Помимо всё тех же проблем со сложностью создания и сравнения состояния окружения (к примеру, как сравнить весь DOM до некоторой операции и после?) добавляются ещё и следующие проблемы:
Cайд-эффекты непредсказуемы и не воспроизводимы
Всё течёт, всё меняется, никто не может дважды войти в один и тот же поток, и к смертной сущности никто не прикоснется дважды!
Из-за того, что внешний мир непредсказуем и постоянно изменяется, мы также не можем воспроизвести результаты вычислений, содержащих сайд-эффекты.
add(a, b) === add(a, b) будет всегда истинно в любых условиях и окружении. Мы можем легко воспроизвести результаты некоторой проблемы с продакшена, просто взяв, к примеру, входные данные с мониторинга и запустив вычисления с этими параметрами. Сайд-эффекты приводят к невоспроизводимым багам: чтобы понять, в чём была проблема, нам надо проанализировать не только наш код, но и состояние всего окружающего мира в тот момент. Это намного более трудоёмко, а порой и вообще невозможно.
Cайд-эффекты не типизируются
Одним из способов контроля кодовой базы и доказательства отсутствия нежелательного поведения программы является статическая типизация.
Очень много копий сломано вокруг того, нужна ли она вообще или нет.
Моё мнение простое: статическая типизация — это инструмент, незаменимый для написания некоторого типа ПО — такого, где очень много кода, много программистов, много связанных подсистем.
Однако вопрос не в этом, а в том, как на использование типизации влияют сайд-эффекты. Рассмотрим пример: предположим, мы имеем функцию, которая по описанию изменения как-то модифицирует DOM :
Сайд-эффекты за счет своей неявности не поддаются описанию типами, и тайп-чекер не может помочь найти проблемы с ними.
Возможным решением является использование имитации Higher-Kinded types для реализации типа Eff при помощи Flow :
В общем, решение не общее и не самое простое.
Усложнение интерактивной разработки кода с сайд-эффектами
Интерактивная разработка начинает набирать популярность. Практически все более-менее популярные языки имеют в стандартной поставке REPL (отдельно или в составе дебаггера). Современные браузеры вообще позволяют писать код прямо в них.
Появляются и отдельные IDE, нацеленные именно на интерактивную разработку. К примеру, Light table, позволяющая в реальном времени следить за результатами вычислений:
Главное преимущество интерактивной разработки — быстрая ответная реакция от только что написанного кода — в таком случае сводится на нет тем, что нам необходимо постоянно наблюдать состояние окружающего мира и периодически исправлять его. Например, восстанавливать удалённого юзера.
Для кода с сайд-эффектами сложно применить тестирование, основанное на проверке свойств
Тестирование, основанное на проверке свойств, или генеративное тестирование, или property-based тестирование — техника, позволяющая описывать свойства какой-то программной сущности (функции, к примеру) и проверять её при помощи генерации входных параметров.
Это очень мощная техника, которая позволяет доказать (с некоторой долей вероятности, конечно же) некоторые утверждения о программном коде. Она становится особенно важной в языках без сильной статической системы типов.
Но, как я отметил в предыдущей своей статье, крайне сложно определить какое-либо свойство для кода с сайд-эффектами — за счет их непредсказуемости.
Мелкие вредители, вредящие по-крупному
Сайд-эффекты — как гремлины, ломают все доступные программисту инструменты, до которых доберутся: типизация, тесты, интерактивные среды, статические анализаторы в IDE, код-ревью.
Но почему это всё действительно важно? Ну да, что-то стало сложнее сделать, но программисты привыкли к борьбе со сложностями. И в отдельных пунктах я приводил результаты такой борьбы — инструменты, которые призваны хоть как-то уменьшить негативное влияние сайд-эффектов.
Проблема в том, что сайд-эффекты не только усложняют написание и работу с самим кодом, но и «ломают» два базовых способа разработки ПО. И это уже реальная проблема.
Два сломанных способа разработки ПО
На самом высоком уровне, по большому счету, существует только два способа разработки. Всё остальное — либо их комбинации, либо производные.
«Сверху-вниз» a.k.a Нисходящий стиль a.k.a Top-Down
Определяем спецификацию самого верхнего уровня API — описываем входное и выходное воздействие:
Осталось придумать, как записывать спецификацию для описания входных и выходных данных:
В идеале она должна описывать все возможные входные воздействия и результаты довольно общим образом — тесты подходят не очень хорошо, так как они описывают отдельные кейсы вместо общего поведения системы.
Мы должны иметь возможность проверить, что разработанная нами программа соответствует изначальной спецификации, иначе при имплементации есть большой шанс получить значительное расхождение со спецификацией. Диаграммы и прочие способы, связанные с ИЗО, не дадут нам такой возможности.
Вы, наверно, уже догадались, что лучше всего здесь подойдёт хорошая система типов.
Люди иногда спрашивают: «Что служит аналогом UML для Haskell?». Когда меня впервые спросили об этом 10 лет назад, я подумал: «Ума не приложу. Может быть, нам стоит придумать свой UML». Сейчас я думаю: «Это просто типы!». Люди рисуют UML-диаграммы, чтобы понять общую схему программы. Именно этим занимаются программисты на функциональных языках и на Haskell, когда придумывают сигнатуры типов для модулей и функций в этих модулях.
Однако, как мы выяснили, без определённых уловок большая часть систем типов не способны работать с сайд-эффектами и уж точно не могут вывести типы таких эффектов из контекста. Можно было бы, конечно, заменить типы тестами (что, например, сделано во всем известном Test Driven Development), но, как мы уже увидели, тесты не очень хорошо подходят для этого из-за своей дискретной природы, к тому же они тоже страдают от сайд-эффектов.
Таким образом сайд-эффекты ломают первый базовый способ разработки ПО. Но, может, со вторым нам повезёт больше?
«Снизу-вверх» a.k.a Восходящий стиль a.k.a Bottom-Up
Мы можем пойти с другой стороны.
Уже по описанию задачи видно, что нам надо будет уметь выводить что-то на экран и надо уметь складывать. Мы не будем пытаться определить точные спецификации. Вместо этого просто напишем общие и минимально необходимые функции для этого. Больше всего эти функции будут похожи на отдельные небольшие библиотеки (очень малоспецифичные и очень переиспользуемые единицы), так как мы ещё не знаем, что за API нам придётся с их помощью строить.
Затем строим из этих функций API более высокого уровня:
Для такого итеративного процесса нам необходим инструмент, позволяющий легко экспериментировать с небольшими кусочками кода и иметь возможность быстро запустить отдельные функции на разных входных данных. При этом в процессе разработки нам не так важно зафиксировать некоторый результат и уметь его воспроизводить — вероятней всего, мы редко будем менять имплементацию уже написанного API. Тесты тут будут скорее мешать низкой скоростью ответной реакции и своей хрупкостью.
Однако, как мы помним, REPL теряет свое главное преимущество (быстрый отклик) при разработке кода с сайд-эффектами. Второй фундаментальный способ тоже не выдержал этой битвы.
Но ведь не весь наш код содержит сайд-эффекты? И, может, все эти неприятности касаются только тех участков, в которых мы их используем? Может, просто стараться использовать поменьше «грязных» функций и побольше «чистых»?
Лед-9 для программного кода
— Итак, в этом романе мир погибает потому, что во льду обнаружена молекула, которая при соприкосновении с водой превращает её в лед. А поскольку все воды мира связаны — пруд с ручьем, ручей с рекой, река с озером, озеро с океаном — таким образом, весь мир замерзает и погибает. И эта молекула называется «Лед-9».
Асинхронность и сайд-эффекты выглядят довольно связанными проблемами — решив только одну из них, вы не избавитесь от всех их недостатков, они лишь переместятся. С другой стороны, хорошее решение одной из этих проблем может помочь решить другую. В дальнейшем мы увидим, что это не случайно и на самом деле оба этих явления представляют собой лишь частные случаи более фундаментальной проблемы отсутствия общего способа абстракции control-flow программы и выражения его first-class значениями.
Но самое ужасное в таких функциях было то, что они заражали весь код, в котором использовались. Обычная функция при использовании в ней функции с коллбэком переставала возвращать результат через return и начинала прокидывать его в коллбэк — и, в свою очередь, сама становилась «ядом» для использующего её кода.
Появилась даже метафора двухцветного языка:
Все функции в языке делятся на «красные» и «синие». И чтобы вызвать «красную» функцию в «синей», нам необходимо перекрасить «синюю» функцию в красный цвет.
Поэтому всё то же самое применимо и к ним:
Рассмотрим пример. Допустим, у нас есть такая иерархия вызовов:
Все вызовы чистые и предсказуемые. С ними нет никаких проблем.
Но неожиданно нам понадобилось кэшировать результаты вычисления функции calcForItem в localStorage :
И наша иерархия стала выглядеть так (красным отмечены функции с сайд-эффектами ):
Изменив код всего одной функции, мы изменили свойства (в плане тестируемости, надёжности, композируемости) для всего стека вызовов.
В некотором смысле мы теряем контроль над своим кодом. Его поведение может измениться, хотя он сам останется прежним — просто API, на котором основан наш код, внезапно станет «грязным» и «заразит» его.
In Soviet Russia side-effects control you!
Если мы не контролируем ПО, то оно начинает контролировать нас (разработчиков). В результате всего вышесказанного у нас получается код, который:
нельзя полноценно протестировать, да и, чтобы протестировать хоть как-то, нужно приложить много усилий — из-за этого мы пишем недостаточно тестов. Проверьте свое покрытие кода с сайд-эффектами и кода, работающего только с данными — скорее всего, во втором случае цифра будет намного выше;
нельзя верифицировать или попробовать доказать его свойства при помощи property-based тестов — у большей его части просто нет каких-либо предсказуемых свойств;
неудобен для работы в интерактивной среде ( REPL ), потому что там не получится работать с DOM-элементами или безопасно послать HTTP-запрос;
практически не поддается рефакторингу, так как сайд-эффекты создают неявные зависимости;
непредсказуем — невозможно создать надёжные инструменты воспроизведения поведения приложения. Обычно не является проблемой по результатам мониторинга понять, что произошо. Но вот почему так произошло — может быть совершенно неясно, так как части приложения влияют друг на друга неявно;
очень тяжело переиспользуется. Иногда без внесения правок в исходники нельзя переиспользовать то или иное решение. Поэтому наученные горьким опытом разработчики зачастую стремятся не переиспользовать крупные части своего приложения (не говоря уже о больших и сложных сторонних компонентах), так как не ясно, возможно ли будет избавиться от некоторых нежелательных действий, если они вдруг станут не нужны.
При этом разработчики сами по себе не хотят писать такой код. Почти любой разработчик скажет, что код должен быть хорошо тестируемым, переиспользуемым и так далее. Нас учат этому с самого начала работы в индустрии.
Однако сайд-эффекты в нашем коде вынуждают нас частично отказаться от всех хороших практик и практически всех доступных программисту инструментов. Софт, который контролирует людей? Я знаю, кому это точно понравится:
При этом мы не пытаемся избавиться от этого контроля и воспринимаем его как что-то само собой разумеющееся. Все эти проблемы давно известны, но мы не пытаемся воздействовать на их причину, а только исправляем отдельные симптомы:
I have a dream.
Попытки решать фундаментальную проблему, борясь только с её отдельными проявлениями, вряд ли могут увенчаться успехом.
Нам необходимо фундаментальное решение проблемы сайд-эффектов в нашем коде. Причём оно должно было максимально общим — не привязанным к какому-то фреймворку или инфраструктуре и не навязывающим какую-либо конкретную архитектуру. Оно должно решать ровно одну проблему и делать это хорошо.
Но как мы можем создать такое решение?
Но мы можем полностью отделить логику нашего приложения от сайд-эффектов.
Всё наше приложение станет полностью чистой функцией — будет явно принимать все входящие воздействия и явно возвращать выходные. А сайд-эффекты будут исполняться отдельно от основного приложения.
Существует минимум 3 способа сделать это, и все они основаны на теоретических основах Computer Science, разработанных около 40 лет назад.
Все эти способы объединяет то, что они созданы для абстракции control-flow программы. Control-flow — это скелет нашей программы, её базис, поэтому эти способы возникают при решении большей части проблем в Computer Science — не только при решении проблемы сайд-эффектов. Однако это тема для следующей статьи.