Когда я работал на C# в PartsTrader, я начал замечать сходство между тем, что ищет предметно-ориентированный дизайн, и тем, что делает функциональное программирование. Или, скорее, что должен делать FP, чтобы быть полезным в реальном мире.
В настоящее время я разрабатываю Javascript для одного клиента и функциональный язык Elm для другого. Ранее я работал в двух компаниях .Net. Один из них — PartsTrader — был без ума от DDD.
Итак, я говорю об отделении чистых функций от побочных эффектов. В DDD идея состоит в том, чтобы ограничить бизнес-логику, оставив за пределами круга все вводы-выводы и внешние интерфейсы.
Whamo, когда вы смотрите на функциональную среду, такую как Elm, у вас есть все чистые функции, отделенные от беспорядочных операций ввода-вывода и внешних функций javascript.
Разница в том, что в Elm это разделение является обязательным. В DDD и объектно-ориентированных языках это добровольное проектное решение с возможностью прочтения серьезных книг, чтобы убедить вас, что вы делаете правильно, лол.
Тем не менее, он все еще возвращается к неизменности. Функциональное программирование дает вам это сразу. В нефункциональных языках это по-прежнему отличная идея, но вам нужно сделать выбор. Преимущество заключается в том, что ваш код легче отлаживать, поскольку то, что входит и выходит, остается постоянным на каждом уровне.
В Elm весь код неизменяем — думайте об этом как об одной большой функции, которая вызывается по мере необходимости. Все побочные эффекты будут выполняться средой выполнения, а затем функция снова вызывается.
Это имеет некоторые интересные преимущества. Если вы хотите увидеть, что делает ваша программа, просто посмотрите на большую функцию «обновления», которая находится в нижней части этого дерева, и на все, что она делегирует. Кроме того, со строгой типизацией, если вы вносите какие-либо изменения, которые нарушают работу, вы очень быстро обнаружите это при компиляции, а сообщения об ошибках просто «знают» так много о том, что вы делаете.
Это не умаляет достоинства Visual Studio .Net при использовании C#. Он «знает» чертовски много еще до того, как вы его скомпилируете, благодаря работе, проделанной на протяжении многих лет некоторыми очень умными людьми.
В нефункциональных языках также рекомендуется передавать любые значения, которые могут изменяться случайным образом, чтобы у вас все еще были функции, пригодные для модульного тестирования — внедрение зависимостей. В Elm функции, вызывающие побочные эффекты, не возвращают ничего обратно в код и поэтому не влияют на возвращаемое значение. Они отправляются в среду выполнения, которая затем возвращает значения через канал обновления сообщений, как будто их сгенерировала какая-то волшебная фея.
Как бы то ни было, разработка на Javascript — это то место, где мы отправимся в путь в этом обсуждении. С одной стороны, это функциональный язык, в котором функции являются первоклассными, и ссылки на них можно передавать. С другой стороны, это настолько свободно, что вы можете иметь побочные эффекты где угодно. Вы действительно не знаете с некоторыми функциями, что может выйти на другом конце. Чтобы затянуть это, требуется изрядное количество накладных расходов.
Я работаю над старой базой кода JS, которую я в значительной степени преобразовал в ES6. Хотя я внедрил Webpack, я уклонился от введения каких-либо новых фреймворков, таких как React и Angular, которые я использовал раньше. Я использую немного нативного JSX в качестве короткого пути для создания шаблонов форм и меню, но это уже другая история.
С обычным JS вы по-прежнему можете придерживаться стратегии сделать вещи как можно более неизменными. Опять же, это означает выделение всего, что является побочным эффектом, до тех пор, пока ваши функции не станут чистыми.
В моем случае я хотел бы начать реорганизацию кодовой базы, чтобы она больше походила на структуру Elm с деревом логики обновления, обновляющей модель, и набором функций просмотра, которые просто отражают изменения в модели — все максимально чисто. Я все еще работаю над тем, как лучше всего это сделать в сочетании с интенсивным использованием Mapbox и Leaflet в приложении.
Бывают также моменты, когда императивный код на Javascript просто легче понять и быстрее реализовать, а прагматичность, безусловно, является хорошим качеством. Возможно, лучше всего оставить комментарий в таких функциях, чтобы они не включали побочные эффекты и не передавали ничего внешнего.
Я считаю, что неизменность и разделение побочных эффектов — одна из основных целей, к которым стоит стремиться при разработке программного обеспечения. Если это не может быть достигнуто немедленно, это должно, по крайней мере, рассматриваться как предпочтительное направление.
Я уверен, что при таком подходе получится что-то более легкое для чтения, поддержки и добавления.
