let’s assume I have a task to create a Set of class names. To remove duplication of .getName() method calls for each class, I used org.apache.commons.collections.CollectionUtils and org.apache.commons.collections.Transformer as follows:
Snippet 1:
Set<String> myNames = new HashSet<String>();
CollectionUtils.collect(
Arrays.<Class<?>>asList(My1.class, My2.class, My3.class, My4.class, My5.class),
new Transformer() {
public Object transform(Object o) {
return ((Class<?>) o).getName();
}
}, myNames);
An alternative would be this code:
Snippet 2:
Collections.addAll(myNames, My1.class.getName(), My2.class.getName(), My3.class.getName(), My4.class.getName(), My5.class.getName());
So, when using functional programming approach is overhead and when it’s not and why?
Isn’t my usage of functional programming approach in snippet 1 is an overhead and why?
8
As others noted, you can’t really use a functional approach in Java, because it is way too verbose and simply lacks a lot of necessary features. So the resulting code will usually look more complex and ugly. Sometimes it is still worth it—because the alternative would include even more duplication and/or other ugliness—sometimes it isn’t. You need to decide on a case by case basis. Try out different approaches and choose the one resulting in the cleanest, simplest code. And don’t bother too much with labels. 🙂 Writing code in “functional” style is not superior per se than any other style—only if your code is actually shorter, cleaner, easier to maintain and extend and/or more efficient in some significant way.
This brings us to another important point. Even if you managed to implement some piece of code in a “functional” way really succinctly, you need to look at it from the point of view of the future maintainers. Will an average Java programmer understand your piece of code if it is so different from the mainstream and well-known Java idioms? Most likely not, which increases the probability of them introducing bugs during future development/maintenance. Your code must have very strong and provable advantages to counterbalance this, and you need to document it well.
5
Java was not designed for functional programming and so, while you can use a functional programming style in Java (immutable state, recursion, function composition, high-order functions, …), you will often miss certain features that facilitate functional programming (ad-hoc syntactic constructs, currying, function composition operator, tail-call optimization, …).
Therefore, even though a functional style in Java can make your code (sometimes) more readable or (more often) more robust, if you really want to use it heavily you’d better use a language that was designed for it. For the JVM you can use Scala or Clojure (here is a short article, that also discusses Groovy). Otherwise, you can try Haskell, Common Lisp, Scheme, F#, Ocaml, and others.
Functional approach usually gives you a better looking, shorter code. But dealing with immutability may result in a performance penalty. I think first snippet looks like overhead because functional syntax in Java is too verbose.
4
Theoretically a functional approach is simpler, more versatile, more verifiable, and easier to understand at-a-glance. If what you end up with doesn’t hit at least one of those goals, then perhaps it’s not the best approach for your circumstances.
Note that functional is, as previously mentioned, a bit of a reach for Java. But not for the JVM. Scala and Groovy are a bit more flexible in that regard and allow you to express functional concepts much more succinctly. And if you want to to all-out functional, there’s always Clojure. All of these target the JVM and should integrate reasonably well into an existing Java project.
If you’re stuck with a Java environment (JVM) but are getting tired of the language itself, I’d recommend trying out Scala or Groovy. It’s a bit like Java with a more modern syntax (or Jython if you’re feeling a twinge of python-envy).
Learning a bit about functional programming can improve the way you write object oriented software. For example the value of immutable objects, lack of side effects and new ways of seeing and appreciating abstractions – favoring ‘verbs’ over ‘nouns’. But as others noted, java is no functional language and you may make the lives of other programmers reading your code hard when using unexpected paradigms.
Have a look at what the authors of google guava have to say about the functional idioms built into their library.