[Haskell-beginners] single responsibility principle vs functional programming

[Joe Van Dyk]

Thanks, I'm starting to get it.

Perhaps what I need to do is take a small standard OOP system and try
converting it to FP.

Or perhaps there's already examples of such a thing I could look at?

Joe

On Wed, Jan 27, 2010 at 11:43 AM, Stephen Blackheath [to
Haskell-Beginners] <mutilating.cauliflowers.stephen at blacksapphire.com>
wrote:
> Joe,
>
> IMHO:
>
> Classes in OOP have several purposes, one of which is to manage the mutation
> of state so as to put a lid on the complexity that could result.  The inside
> of an OOP class is usually a C program, and the outside is (ideally) a
> semi-functional program with interfaces that are simple at the level of
> abstraction where they operate.  The single responsibility principle exists
> to stop the C programs getting big and messy, and to help the programmer to
> build neat layers of abstraction on top of each other by having more
> abstract classes constructed out of less abstract ones.
>
> Functional programming essentially takes the C part away and makes the whole
> program into a layering of abstractions, even at the lowest level.
>
> An FP function more-or-less maps to an OOP class, and the reason why it can
> be a much lighter-weight structure is because the need to manage mutation
> has been removed.  I think the same principle applies, though - an FP
> function should have only one responsibility.
>
> Perhaps in FP the need for this principle to be explicitly stated and
> carefully observed is not so great, though.  If an FP function does two
> things and can be split up, it's not such a big deal, because re-factoring
> is easy in an FP language.  By comparison in OOP, splitting a big messy
> class up is a lot of work with a great risk of breakage. This amplifies the
> importance of applying the single responsibility principle before you start
> writing the class.
>
>
> Steve
>
> Joe Van Dyk wrote:
>>
>> So I'm still pretty new to functional programming.
>>
>> In OOP, you have the concept of each class having a
>> single-responsibility (or reason for changing).  See
>> http://en.wikipedia.org/wiki/Single_responsibility_principle
>>
>> I'm having problems seeing how that concept maps to functional
>> programming.  Perhaps it doesn't?
>>
>



-- 
Joe Van Dyk
http://fixieconsulting.com