# Применяйте принципы функционального программирования

(В оригинале - Apply Functional Programming Principles)

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

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

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

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

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

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

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

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

Автор оригинала - [Edward Garson](http://programmer.97things.oreilly.com/wiki/index.php/Edward_Garson)


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://97-things-every-x-should-know.gitbook.io/97-things-every-programmer-should-know/ru/thing_67.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
