Какие выгоды даёт использование FP? Вот что говорит автор CQS, добавивший функциональщины в OOP, объясняя причины своего решения:
💬 "Referential transparency
Why should we be concerned about side effects in functions? After all it is in the nature of software execution to change things.
The problem is that if we allow functions to change things as well as commands, we lose many of the simple mathematical properties that enable us to reason about our software. As noted in the discussion of abstract data types, when we first encountered the distinction between the applicative and the imperative, mathematics is change-free: it talks about abstract objects and defines operations on these objects, but the operations do not change the objects. (Computing square root of 2 does not change the number two.) This immutability is the principal difference between the worlds of mathematics and computer software.
Some approaches to programming seek to retain the immutability of mathematics: Lisp in its so-called "pure" form, "Functional Programming" languages such as Backus's FP, and other applicative languages shun change. But they have not caught on for practical software development, suggesting that change is a fundamental property of software.
The object immutability of mathematics has an important practical consequence known as referential transparency, a property defined as follows:
Definition: referential transparency
With side-effect-producing functions, referential transparency disappears. Assume a class contains the attribute and the function
Maintaining referential transparency in expressions is important to enable us to reason about our software. One of the central issues of software construction, analyzed clearly by Dijkstra many years ago, is the difficulty of getting a clear picture of the dynamic behavior (the myriad possible executions of even a simple software element) from its static description (the text of the element). In this effort it is essential to be able to rely on the proven form of reasoning, provided by mathematics. With the demise of referential transparency, however, we lose basic properties of mathematics, so deeply rooted in our practice that we may not even be aware of them. For example, it is no longer true that n + n is the same thing as 2 ∗ n if n is the sneaky-like function
By limiting ourselves to functions that do not produce side effects, we will ensure that talking about "functions" in software ceases to betray the meaning of this term in ordinary mathematics. We will maintain a clear distinction between commands, whichchange objects but do not directly return results, and queries, which provide information about objects but do not change them. Another way to express this rule informally is to state that asking a question should not change the answer."
-- "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer
💬 "Referential transparency
Why should we be concerned about side effects in functions? After all it is in the nature of software execution to change things.
The problem is that if we allow functions to change things as well as commands, we lose many of the simple mathematical properties that enable us to reason about our software. As noted in the discussion of abstract data types, when we first encountered the distinction between the applicative and the imperative, mathematics is change-free: it talks about abstract objects and defines operations on these objects, but the operations do not change the objects. (Computing square root of 2 does not change the number two.) This immutability is the principal difference between the worlds of mathematics and computer software.
Some approaches to programming seek to retain the immutability of mathematics: Lisp in its so-called "pure" form, "Functional Programming" languages such as Backus's FP, and other applicative languages shun change. But they have not caught on for practical software development, suggesting that change is a fundamental property of software.
The object immutability of mathematics has an important practical consequence known as referential transparency, a property defined as follows:
Definition: referential transparency
An expression e is referentially transparent if it is possible to exchange any subexpression with its value without changing the value of e.If x has value three, we can use x instead of 3, or conversely, in any part of a referentially transparent expression. (Only Swift's Laputa academicians were willing to pay the true price of renouncing referential transparency: always carrying around all the things you will ever want to talk about.) As a consequence of the definition, if we know that x and y have the same value, we can use one interchangeably with the other. For that reason referential transparency is also called "substitutivity of equals for equals".
With side-effect-producing functions, referential transparency disappears. Assume a class contains the attribute and the function
attr: INTEGERThen the value of sneaky (meaning: of a call to that function) is always 0; but you cannot use 0 and sneaky interchangeably, since an extract of the form
sneaky: INTEGER is do attr := attr + 1 end
attr := 0; if attr /= 0 then print ("Something bizarre!") end
will print nothing, but would print Something bizarre! if you replaced 0 by sneaky.Maintaining referential transparency in expressions is important to enable us to reason about our software. One of the central issues of software construction, analyzed clearly by Dijkstra many years ago, is the difficulty of getting a clear picture of the dynamic behavior (the myriad possible executions of even a simple software element) from its static description (the text of the element). In this effort it is essential to be able to rely on the proven form of reasoning, provided by mathematics. With the demise of referential transparency, however, we lose basic properties of mathematics, so deeply rooted in our practice that we may not even be aware of them. For example, it is no longer true that n + n is the same thing as 2 ∗ n if n is the sneaky-like function
n: INTEGER is do attr := attr + 1; Result := attr endsince, with attr initially zero, 2 ∗ n will return 2 whereas n + n will return 3.
By limiting ourselves to functions that do not produce side effects, we will ensure that talking about "functions" in software ceases to betray the meaning of this term in ordinary mathematics. We will maintain a clear distinction between commands, whichchange objects but do not directly return results, and queries, which provide information about objects but do not change them. Another way to express this rule informally is to state that asking a question should not change the answer."
-- "Object-Oriented Software Construction" 2nd edition by Bertrand Meyer