OO design patterns vs FP idioms in Java 8

[Victor Nazarov]

I've always percept Visitor-pattern as an implementation of Algebraic Data
Types in Java-like languages. Visitor-pattern is just an implementation of
pattern-matching on ADT-constructors, and this is already present as
language-level feature in all ML-like languages (including Haskell).

Victor Nazarov


On Thu, Oct 3, 2013 at 2:37 AM, Samir Talwar <samir at noodlesandwich.com>wrote:

> 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
> >
> >
> >
>
>