OO design patterns vs FP idioms in Java 8

[Millies, Sebastian]

that’s an interesting observation. However, I’d not like for the discussion to veer off towards the fundamentals of FP. Java is still mainly an OO language, only now that it has got lambdas, we might have more options to do things differently, without pretending that Java were like Haskell.

Case in point: In the Template pattern, we might replace the abstract methods in the superclass by simple members (holding a lambda), getting rid of the subclassing. This could be either interpreted as “absorbing” the pattern or just implementing it differently, the line is blurred, but it would still be recognizable, and perhaps more elegant or succinct. Another case: decorators  are so obviously like functional composition that I doubt I’ll ever do them with constructors again.

These ideas may have some practical relevance to Java programming. We may get new idioms. In contrast, I do not think we could immediately infer anything about the usefulness of the Visitor pattern in Java 8 from observing that in pure FP we do not have objects. (A discussion of purely functional data structures in Java, now that would be an entirely new topic.)


n  Sebastian

From: Samir Talwar [mailto:samir at noodlesandwich.com]
Sent: Thursday, October 03, 2013 12:38 AM
To: Millies, Sebastian
Cc: lambda-dev at openjdk.java.net
Subject: Re: OO design patterns vs FP idioms in Java 8

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<mailto: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<mailto:Sebastian.Millies at softwareag.com>
Sent: Wednesday, October 02, 2013 10:08 AM
To: lambda-dev at openjdk.java.net<mailto: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