2/97: Применение принципов функционального программирования

Это перевод Apply Functional Programming Principles. Автор: Edward Garson.

Из "97-ми вещей, которые должен знать каждый программист".

В последнее время возрождается интерес к функциональному программированию со стороны основного общества разработчиков. Часть причины заключается в том, что свойства функциональных парадигм могут хорошо решать проблемы, связанные со сдвигом нашей отрасли к многоядерности. Однако, хотя это, безусловно, важный аспект применения, это не причина, почему эта заметка призывает вас к изучению функционального программирования.

Изучение парадигмы функционального программирования может значительно улучшить качество вашего кода, который вы пишете в других контекстах. Если вы хорошо её понимаете и применяете, то ваши проекты будут проявлять более высокую степень ссылочной прозрачности.

Ссылочная прозрачность является весьма желательным свойством: она означает, что функция всегда даёт одинаковые результаты для одинаковых входных данных, независимо от того, где и когда она вызывается. Таким образом, оценка функции менее зависит (в идеале: вообще не зависит) от побочных эффектов изменяемых состояний.

Основной причиной дефектов в коде императивных языков являются изменяемые переменные. Каждый, кто читает сейчас это, не раз исследовал, почему некоторые переменные не имеют ожидаемых значений в конкретной ситуации. Семантика видимости может помочь смягчить эти коварные дефекты или, по крайней мере, резко сузить их область для их поиска, но их истинный виновник, в действительности, может быть дизайн кода, который чрезмерно использует изменчивость.

И мы, определённо, не получаем большую помощь в этой области от индустрии программирования. Введение в объектно-ориентированный подход молчаливо поощряет такие конструкции, потому что оно часто показывает примеры, составленные из графов долгоживущих объектов, которые радостно вызывают модифицирующие методы друг друга, что может быть опасным. Тем не менее, с разработкой, ведомой тестами (test-driven design), особенно, когда мы "подделываем роли, а не объекты", ненужная изменчивость может быть выброшена при проектировании.

Конечным результатом является дизайн, который обычно имеет более эффективное распределение ответственностей, с большим количеством более мелких функций, которые работают с передаваемыми им аргументами, а не ссылаются на изменяемые поля. Там будет меньше дефектов, и, кроме того, они будут часто проще в отладке, потому что это проще найти где появилось неверное значение при таком дизайне, чем вывести (найти) конкретный контекст, который приводит к ошибочному состоянию. Этот дизайн имеет гораздо более высокую степень ссылочной прозрачности, и, определённо, ничего не вобьёт в вас эти идеи лучше, чем обучение языку функционального программирования, где эта модель вычислений является нормой.

Конечно же, такой подход не является оптимальным во всех ситуациях. Например, в объектно-ориентированных системах этот стиль часто дает лучшие результаты с т.н. domain model development (т.е. там, где сотрудничество служит для смягчения сложностей бизнес-правил) по сравнению с user-interface development.

Освойте функциональное программирование, так что вы сможете разумно использовать опыт, накопленный в других областях. Ваши системы объектов будут нести блага ссылочной прозрачности и будут гораздо ближе к своим функциональным коллегами, чем вам хотелось бы верить. В самом деле, некоторые даже утверждают, что вершина функционального программирования и объектно-ориентированного подхода являются всего лишь отражением друг друга - вроде как инь и янь.