Thinking functionally - Java 8 in Action: Lambdas, Streams, and Functional-Style Programming - page 362

Referential transparency is a great property for program understanding. It also encompasses a
save-instead-of-recompute optimization for expensive or long-lived operations, which goes
under the name memoization or caching . Although important, this is slightly at a tangent to the
development here, so we defer this explanation to the next chapter, in section 14.5 .
In Java there's one slight complication about referential transparency. Suppose you make two
calls to a method that returns a List. Then the two calls may return references to distinct lists in
memory but containing the same elements. If these lists were to be seen as mutable
object-oriented values (and hence non-identical) then the method wouldn't be referentially
transparent. If you plan to use these lists as pure (immutable) values, then it makes sense to see
the values as equal and hence the function as referentially transparent. In general, in
functional-style code you choose to regard such functions as referentially transparent . We
discuss this issue again in the next chapter, in section 14.5 . We now explore the issue of whether
to mutate from a wider perspective.
13.2.3. Object-oriented vs. functional-style programming
We start by contrasting functional-style programming with (extreme) classical object-oriented
programming before observing that Java 8 sees these styles as mere extremes of the
object-oriented spectrum. As a Java programmer, without consciously thinking about it, you
almost certainly use some aspects of functional-style programming and some aspects of what
we'll call extreme object-oriented programming. As we remarked in chapter 1 , changes in both
hardware (for example, multicore) and programmer expectation (for example, database-like
queries to manipulate data) are pushing Java software-engineering styles somewhat more to the
functional end of this spectrum, and one of the aims of this topic is to help you adapt to the
changing climate.
At one end of the spectrum is the extreme object-oriented view: everything is an object and
programs operate by updating fields and calling methods that update their associated object. At
the other end of the spectrum lies the referentially transparent functional-programming style of
no (visible) mutation. In practice, Java programmers have always mixed these styles. You might
traverse a data structure using an Iterator containing mutable internal state but use this to
calculate, say, the sum of values in the data structure in a functional-style manner (in Java, as
discussed, this can include mutating local variables). One of the aims of the next sections in this
chapter and more generally in the next chapter is to discuss programming techniques and
introduce features from functional programming to enable you to write programs that are more
modular and more suitable for multicore processors. Think of these ideas as additional weapons
in your programming armory.