BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Presentations SOLID: The Next Step Is Functional

SOLID: The Next Step Is Functional

Bookmarks
01:02:03

Summary

Anil Wadghule explains why applying SOLID OO design principles to their extreme leads to Functional Programming.

Bio

Anil Wadghule has worked on Ruby full time for more than 6 years. He has recently worked a lot on Java, JavaScript and Node.js. He loves Ruby and is interested in clean code, design patterns and other good programming practices. He has contributed to different open source projects including Ruby on Rails. He works in 'Equal Experts', Pune where he follows TDD and good programming practices.

About the conference

Our aim is to provide Great events rather than Big events. We want our participants to enjoy a learning experience that is second to none. We pride ourselves on being user focussed, designing then refining all our events to ensure our participants want to come back every year.

Recorded at:

Apr 16, 2015

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • Pendulum...

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    it's hard to disagree with your presentation and the SOLID principles, but wouldn't you think that the pendulum is now swigging too far in the functional direction? There are 4 fundamental concepts to programming: Types (aka Classes), Actions (aka Functions), Relations and ... State (as in control state, i.e. the state that controls which actions are possible or not).

    Do you really think that we can somehow roll up the OO sleeve to make it functional and expect that it will solve all our problems? Don't you think that "patterns" will precisely be needed to properly deal with the missing semantics?

    Patterns are indeed only about teaching people how to properly encode the missing semantics of a deficient formalism. Why don't we actually create a formalism with enough semantics to cover State, Type, Action and Relationships (STAR)?

    TLA+ for instance has very interesting semantics well aligned with these four concepts. For those who don't want to go through the TLA+ spec, I created a small open source framework (in Java, next in Javascript) which aims at implementing as many TLA+ semantics as possible.

  • Re: Pendulum...

    by Joseph Abrahamson,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    I think ontological principles for describing program, of which both SOLID and STAR fall, will always be prescriptive and partial. The nice thing about functional programming foundationally is that it actually forms a sensible foundation due to its tight connection with intuitionistic logic.

    Since you can embed OO in FP very neatly and FP forms a strong foundation, it seems that an industry which is embracing understanding and exploiting foundational structure will be better off than one that doesn't and, from this position, valuable "insights of art" can be properly developed which might include analyses like STAR and SOLID.

    On the other hand there's a reasonable question as to whether FP can act as more than merely foundational. Another way of asking this question is to ask whether functional mechanisms are too cumbersome for describing meaningful models of thought that programmers would like to use. For instance, while OO is neatly encoded in FP, if you want OO that, say, resembles Java then you will be in for a very difficult encoding.

    My thoughts here—which, I'd like to clearly distinguish from the ones before, are much closer to mere opinion—are that FP is not too cumbersome and instead provides insight into better, more compositional abstractions than the ones programmers are used to (from OO). It may be the case in time that FP does feel too cumbersome—from a Haskell point of view, the most immediate example would be desiring to always have ambient reference state, to always live in an ambient reference state monad—but my belief is that this pathway of development will lead to higher-level "default" abstraction states which are *far* more principled than OO as it is known today.

  • Re: Pendulum...

    by Jean-Jacques Dubray,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Joseph,

    I would encourage anyone who writes code to read this paper from Dr. Lamport: Computation and State Machines. This should close the debate once and for all about this FP vs OO nonsense. The arguments put forward make sense but it's a bit like saying a screwdriver is better than a hammer. The reality is that it depends.

    Hipsters, which voice is often over-amplified on InfoQ, love to claim having discovered the next "magic bullet"... but after decades, we all know how things pan out. Nothing beats understanding what you are trying to accomplish and use the proper tool(s) for it.

    Opinions are cheap, and make sure you understand you use them at your own risks.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT