Towards Greater Code Reuse

[William la Forge]

Code reuse is for me the holy grail of software. It is something we lost in large measure with the adoption of top-down development. And OO has only complicated the matter. For some time now I have advocated the use of factories and interfaces as a means of decoupling, but writing reusable code has continued to be a bit of a lost art. But then, I was a Java developer.

Having been exposed to Clojure, I've come to realize that a function is the smallest unit of reusable code, not a class. Simply moving logic from methods to functions (or to static methods, if you are still using Java) opens up a lot of possibilities. Mind, I still advocate the use of interfaces for method polymorphism, but limit method bodies to be little more than a call to a function or a property accessor.

Doing this allows us to avoid class extensions and mind-numbing class hierarchies. The code becomes much clearer, defining new classes becomes much easier, and the need to refactor the code is greatly diminished. And writing reusable functions is much easier than writing reusable classes.

from https://github.com/laforge49/aatree/wiki/Towards-Greater-Code-Reuse

[Frank Castellucci]

Reuse is a matter of perspective.

During the OO marketing blitz of the 90's, promise of re-use (C++, etc etc) convinced many to jump in the pool. So today there is a tremendous amount of abstract and deep hierarchies build with the notions that: "Someday this may be useful to specialize from this Class thereby enabling 're-use'" ... BS!!!! There is much more code that does NOTHING in the hierarchy other than putting a drag on the timeliness of delivery.

True reuse emerged at the macro level (i.e.Module orientation, Re-provisionable services, Web Services, etc.) while the micro level adventure leaving bloated unmaintainable artifacts in  it's wake.

The fundamental essence of functional approach has done more for reuse at the micro level then all OO languages combined. IMHO.

Off peanut gallery soap-box

Frank 

[Colin Yates]

My 1.5 cents:

 - code re-use is easier in FP because of the common abstractions - sequences etc.

 - code re-use is easier in FP because of the separation of state and functions

 - knowledge learned from creating a piece of code is far more likely to be re-used than the code itself

 - refactoring for code re-use is often _the_ definition of early optimisation

 - code re-use will never take off because we are all hard-wired to build our own solution

 - service re-use - yep

 My soap-box just collapsed under the weight of my unfounded assertions so I’m out.

--
You received this message because you are subscribed to the Google
Groups "Clojure" group.
To post to this group, send email to clo...@googlegroups.com
Note that posts from new members are moderated - please be patient with your first post.
To unsubscribe from this group, send email to
clojure+u...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/clojure?hl=en
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William la Forge]

Refactoring for reuse is a kind of early optimization? Agreed! Generally for me it waits until the second or third rewrite, as by then I have a bit of an idea about where I am headed with the code.

OTOH, I finally realized that when I don't know where I am going with something, keeping the logic in functions instead of methods is probably safest. I'm thinking now that methods should mostly just be used for their polymorphism as just a very thin layer over a set of interfaces.

I was so impressed with the advantages of Java over C++ when I started using it 20 years ago. But now that I've been exposed to Clojure, I'm inclined to minimize my use of OO and use objects mostly as what I used before OO: dispatch tables!

[Colin Yates]

It might just be me, but I also find the cost of the explicit coupling that is re-use is often far more expensive than any saving offered by re-use of a bunch of text. I also find this _more_ expensive in Clojure than Java as refactoring in Java was pretty robust (IntelliJ is incredibly powerful for this). 

[Gary Trakhman]

There are a lot of strategies to deal with the coupling of reuse.  I find that using pure functions makes it easy to split off responsibilities after the fact and add multiple entry points (the hard thing becomes naming those functions).  Eventually a new 'essence' of the abstraction will show itself and inspire a larger refactor.  That's something I really miss when doing java.  

Also, I feel that the reusable clojure code is always doing more work than corresponding java code, so my frustration in refactoring is much greater with java and its IDEs.  The refactorings are always superficial compared to what I'm trying to express, and in clojure I can work with data contracts easily.  I often end up writing a new version of the reusable abstraction, writing adapters (just data transformations) from the old to the new, then gutting the old implementation, then hopefully gutting the adapters over time.  Clojure's data focus makes this easy.

[Colin Yates]

+1 to pipe-lines of immutable data transformations. That was the biggest paradigm shift for me coming to FP and made the world a much better place.

[William la Forge]

It is obvious to me now that I am still very much a newbie to Clojure!

You received this message because you are subscribed to a topic in the Google Groups "Clojure" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clojure/mLzj2aYa2Cg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clojure+u...@googlegroups.com.