views:

127

answers:

4

Should one apply functional programming practices at the design level, i.e. when we identify and design class hierarchy, or is it applicable only when it comes to writing function bodies?

What I feel is that we do the design process applying normal OOPs techniques and write implementations using a functional approach.

Your thoughts, please!

+4  A: 

The design process should be OOP agnostic. Maybe we'll need objects and classes, maybe we won't. Maybe a large portion will use functional techniques. Maybe all it needs is a 5 minute perl script. It depends on what we're trying to accomplish.

That said, an argument could be made that OOP may get in the way of a purely functional design. Other arguments could be made that it doesn't. Another argument could be made that you just need to use your best judgement and balance the two paradigms. Others will chime in and say the two approaches are orthogonal and can be combined without conflict.

But it's all abstract really. The answer is MU. Pose a real problem you have, and then we'll be able to tell you whether a functional or oop approach is appropriate, and at what level.

Breton
Thanks all for such wonderfull answers. I came to the following conclusion that FP is good at implementation level and OOPs at more abstract level.
pokrate
A: 

I am a bit biased towards the FP approach at design if you want to implement in FP.
But, Breton makes a good point that the selection is subjective.

References.

  1. Another Stackoverflow question: How can I use functional programming in the real world?.
  2. JavaScript: Use functional programming techniques to write elegant JavaScript
  3. F# primer: Use Functional Programming Techniques in the .NET Framework
  4. Discussion thread: Why people don't use functional programming?
  5. Links: list of functional programs applied to real-world tasks
nik
A: 

I agree that an OOP high-level decomposition with FP implementation techniques is a good strategy; I discuss this some in a blog:

How does functional programming affect the structure of your code?

Brian
Also, OO doesn't necessarily mean "state". When I started using Smalltalk, I realized that code often returns new objects, copies, or treats objects as stateless values. In fact this reinforces OO-ness: you can just send messages without worrying about unwanted side effects. of course it's still possible to write a noodly mess of stateful code, but somehow the stateless style feels natural.PS: the Command pattern you describe is degenerate; in OO languages with closures it's not needed. But Command is still useful when you need to setup/record/undo changes (e.g prevayler-style persistence).
Damien Pollet
+1  A: 

Brian McNamara, of the F# Development team, has an interesting blog titled How does functional programming affect the structure of your code?.

I tend to agree with his assessment that functional programming tends to have the largest influence on actual code structure, at the level of implementation and individual routines, and less influence on overall architecture, at the level of modules and subsystems.

That said, I also think that FP can influence how the problem is attacked, and can often lead to entirely different approaches, such as DSL's, async code, filter graphs, actors, etc., but these can all be considered "in the medium" solutions which don't effect the larger architecture, such as distributed, REST, client-server, etc.

James Hugard