OO design patterns vs FP idioms in Java 8

[Samir Talwar]

The following should be taken with a grain of salt. I haven't read the
Design Patterns book; this is just my observations from real-world usage,
which is subject to argumentum ad anecdotum.

I'd argue that the Visitor pattern becomes an anti-pattern in the
functional paradigm. The visitor pattern is really a mechanism to
selectively allow access to internal state and therefore decouple functions
from the objects on which they act, which is necessary because of the
"tell, don't ask" principle. Decomposition of data structures is encouraged
in FP, so visitors aren't really necessary. We just have functions and data
structures, not objects.

— Samir.


On Wed, Oct 2, 2013 at 8:15 PM, Millies, Sebastian <
Sebastian.Millies at softwareag.com> wrote:

> after some more searching I discovered these two articles by Neal Ford in
> the “Functional Thinking” on IBM developerworks.
> https://www.ibm.com/developerworks/java/library/j-ft10/index.html
> https://www.ibm.com/developerworks/java/library/j-ft11/
>
> He says:
>
> In the functional-programming world, traditional design patterns generally
> manifest in one of three ways:
>
> 1.    The pattern is absorbed by the language.
>
> 2.    The pattern solution still exists in the functional paradigm, but
> the implementation details differ.
>
> 3.    The solution is implemented using capabilities other languages or
> paradigms lack. (For example, many solutions that use metaprogramming are
> clean and elegant — and they're not possible in Java.)
>
> My reading up to now could be summarized like this:
>
>
> ·         Strategy
>
> o    take functions that implement a strategy
>
> o    provide functions to choose from
>
> ·         Template and Factory Method
>
> o    these patterns also relate to supplying concrete behavior
>
> ·         Command
>
> o    disappears, because object wrapper not needed for portable
> functionality
>
> ·         Chain of Responsibility and Decorator
>
> o    composition of (partial) functions
>
> ·         Adaptor
>
> o    adaptor classes can be conveniently replaced by (composable) lambdas
>
> ·         Visitor
>
> o    more complex, no direct correspondence
>
> o    special case for streams: reduce
>
> I’d welcome any comments, additional examples of correspondences.
>
>
> n  Sebastian
>
>
>
> From: Sebastian.Millies at softwareag.com
> Sent: Wednesday, October 02, 2013 10:08 AM
> To: lambda-dev at openjdk.java.net
> Subject: OO design patterns vs FP idioms in Java 8
>
> Hi there,
>
> has anyone written about the relation of OO design patterns (by which I
> mean the usual GoF patterns) to functional programming idioms that may be
> applicable in Java 8? The reason I ask is that I think it's possible that
> ideas from FP may inform our approach to design patterns in the new Java
> release. I have searched Google a bit, but found no really coherent
> discussion.
>
> Much of it just boils down to higher order functions. For example, it
> seems obvious that Decorator (and Chain of Responsibility and Adapter, too)
> are forms of functional composition. Strategy is just passing a lambda that
> implements the concrete strategy.
>
> But other patterns are more complicated. Visitor is often cited as being
> fold, which is almost reduce in separating the traversal, in this case of a
> stream, from the algorithm operating on the stream elements. But would this
> carry over to other structures than streams in Java 8?
>
> Some typical FP things would clearly be inappropriate in Java. Obviously,
> Java is not being transformed into Haskell, and I don’t expect to use
> monadic programming  instead of throwing exceptions ;-) However, other FP
> ideas may now be really viable in Java.
>
> I suspect this might be off-topic for this list, as it’s a bit
> speculative. But I find the question just naturally suggests itself.
>
>
> n  Sebastian
>
> Software AG – Sitz/Registered office: Uhlandstraße 12, 64297 Darmstadt,
> Germany – Registergericht/Commercial register: Darmstadt HRB 1562 -
> Vorstand/Management Board: Karl-Heinz Streibich (Vorsitzender/Chairman),
> Dr. Wolfram Jost, Arnd Zinnhardt; - Aufsichtsratsvorsitzender/Chairman of
> the Supervisory Board: Dr. Andreas Bereczky - http://www.softwareag.com
>
>
>