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

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

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

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

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

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

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

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

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

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

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