Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #25427 > unrolled thread

OO Design Patterns vs FP

Back to article view | Back to comp.lang.java.programmer

Contents

  OO Design Patterns vs FP Sebastian <news@seyweiler.dyndns.org> - 2013-10-02 09:33 +0200
    Re: OO Design Patterns vs FP Jeff Higgins <jeff@invalid.invalid> - 2013-10-02 11:29 -0400
      Re: OO Design Patterns vs FP Sebastian <news@seyweiler.dyndns.org> - 2013-10-02 18:21 +0200
        Re: OO Design Patterns vs FP Jeff Higgins <jeff@invalid.invalid> - 2013-10-02 13:31 -0400
          Re: OO Design Patterns vs FP Jeff Higgins <jeff@invalid.invalid> - 2013-10-02 15:16 -0400
          Re: OO Design Patterns vs FP Sebastian <news@seyweiler.dyndns.org> - 2013-10-02 21:31 +0200
            Re: OO Design Patterns vs FP Jeff Higgins <jeff@invalid.invalid> - 2013-10-02 15:55 -0400

#25427 — OO Design Patterns vs FP

Hello there,

has anyone written about the relation of OO design patterns (by which I 
mean the usual GoF patterns) to functional programming idioms?

For example, it seems obvious that Decorator (and Chain of 
Responsibility and Adapter, too) are forms of functional composition. 
But other patterns are less obvious. Visitor might be fold, but you'd 
have to throw in the polymorphism, etc.

The reason I ask, of course, is lambdas in Java 8. I think it's possible 
that ideas from FP may inform our approach to design patterns in current 
OO languages.

-- Sebastian

[toc] | [next] | [standalone]

#25431

On 10/02/2013 03:33 AM, Sebastian wrote:
> Hello there,
>
> has anyone written about the relation of OO design patterns (by which I
> mean the usual GoF patterns) to functional programming idioms?
>

relation+of+OO+design+patterns+to+functional+programming+idioms
<http://bit.ly/15ILqCW>

We could also check Sebastian Millies: Dev-Blog.

[toc] | [prev] | [next] | [standalone]

#25432

Am 02.10.2013 17:29, schrieb Jeff Higgins:
> On 10/02/2013 03:33 AM, Sebastian wrote:
>> Hello there,
>>
>> has anyone written about the relation of OO design patterns (by which I
>> mean the usual GoF patterns) to functional programming idioms?
>>
>
> relation+of+OO+design+patterns+to+functional+programming+idioms
> <http://bit.ly/15ILqCW>

I did Google a bit before posting, you know. One finds a couple of more 
or less incoherent discussions on blog posts, then one finds very 
theoretically-minded stuff that's sort of _inside_ FP.

Probably the nearest thing to what I'm looking for, but not quite, is 
Neal Ford's "Thinking functionally" series on IBM developerworks. But 
even that often discuss things in the context of Groovy and Scala, not 
Java, or is concerned with third-party frameworks like Totally Lazy 
(though being lazy is often a good thing, how does that relate to OO 
design patterns?)

> We could also check Sebastian Millies: Dev-Blog.
>

Well, that's me. I wasn't aware I'd said much that was relevant to this 
topic.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#25433

On 10/02/2013 12:21 PM, Sebastian wrote:
> Am 02.10.2013 17:29, schrieb Jeff Higgins:
>> On 10/02/2013 03:33 AM, Sebastian wrote:
>>> Hello there,
>>>
>>> has anyone written about the relation of OO design patterns (by which I
>>> mean the usual GoF patterns) to functional programming idioms?
>>>
>>
>> relation+of+OO+design+patterns+to+functional+programming+idioms
>> <http://bit.ly/15ILqCW>
>
> I did Google a bit before posting, you know. One finds a couple of more
> or less incoherent discussions on blog posts, then one finds very
> theoretically-minded stuff that's sort of _inside_ FP.

The subject has been widely bantered about.
Here's one discussion begun in 2008:
<http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns?rq=1>

[toc] | [prev] | [next] | [standalone]

#25434

Just another breadcrumb memento for me. Patterns. Thanks.
<http://c2.com/cgi/wiki>

[toc] | [prev] | [next] | [standalone]

#25435

Am 02.10.2013 19:31, schrieb Jeff Higgins:
> On 10/02/2013 12:21 PM, Sebastian wrote:
>> Am 02.10.2013 17:29, schrieb Jeff Higgins:
>>> On 10/02/2013 03:33 AM, Sebastian wrote:
>>>> Hello there,
>>>>
>>>> has anyone written about the relation of OO design patterns (by which I
>>>> mean the usual GoF patterns) to functional programming idioms?
>>>>
>>>
>>> relation+of+OO+design+patterns+to+functional+programming+idioms
>>> <http://bit.ly/15ILqCW>
>>
>> I did Google a bit before posting, you know. One finds a couple of more
>> or less incoherent discussions on blog posts, then one finds very
>> theoretically-minded stuff that's sort of _inside_ FP.
>
> The subject has been widely bantered about.
> Here's one discussion begun in 2008:
> <http://stackoverflow.com/questions/327955/does-functional-programming-replace-gof-design-patterns?rq=1>
>
>
Here's a useful quote from Neal Ford's article series on IBM developerworks:

<quote>
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.)
</quote>

My reading so far could be summarized like this:

- Strategy
   -- take functions (Java 8 lambdas) that implement a strategy
   -- provide functions to choose from

- Template and Factory Method
   -- these patterns also relate to supplying concrete behavior
   -- abstract template methods may become simple members (lambdas), 
concrete subclasses disappear

- Command
   -- disappears, because object wrapper not needed for portable 
functionality in Java 8

- Chain of Responsibility and Decorator
   -- composition of (partial) functions

- Adaptor
   -- adaptor classes can be conveniently replaced by (composable) lambdas

- Visitor
   - more complex, no direct correspondence
   - special case for streams: reduce (decouple traversal of stream from 
operation on stream elements)


I’d welcome any comments, additional examples of correspondences etc.

-- Sebastian

[toc] | [prev] | [next] | [standalone]

#25436

On 10/02/2013 03:31 PM, Sebastian wrote:

> Here's a useful quote from Neal Ford's article series on IBM
> developerworks:
>
> <quote>
> 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.)
> </quote>
>
> My reading so far could be summarized like this:
>
> - Strategy
>    -- take functions (Java 8 lambdas) that implement a strategy
>    -- provide functions to choose from
>
> - Template and Factory Method
>    -- these patterns also relate to supplying concrete behavior
>    -- abstract template methods may become simple members (lambdas),
> concrete subclasses disappear
>
> - Command
>    -- disappears, because object wrapper not needed for portable
> functionality in Java 8
>
> - Chain of Responsibility and Decorator
>    -- composition of (partial) functions
>
> - Adaptor
>    -- adaptor classes can be conveniently replaced by (composable) lambdas
>
> - Visitor
>    - more complex, no direct correspondence
>    - special case for streams: reduce (decouple traversal of stream from
> operation on stream elements)
>
>
> I’d welcome any comments, additional examples of correspondences etc.
>
A bit more useful as a starting point for discussion. Thanks. :)

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web