0

I got in touch with the functional programming paradigm (haskell, scala) and like the concept. I'm trying to incorporate these functional principles in my every day work.

Here an example

public class Functional
{

  private final Object o1;
  private final Object o2;

  public Functional(Object o1, Object o2)
  {
    this.o1 = o1;
    this.o2 = o2;
  }

  /*
   * method has side effects 
   */
  private void method()
  {
    //    o1.someChange();
    //    ...
    //    o2.someChange();
  }

  /*
   * method has no side effects - it only uses its parameters
   */
  private static void method(Object o1, Object o2)
  {
    //    o1.someChange();
    //    ...
    //    o2.someChange();
  }

  public void work()
  {
    method(o1, o2);
  }

  public static void main(String[] args)
  {
    Functional f = new Functional(new Object(), new Object());
    f.work();
  }
}

I find the static method easier to maintain, also for people who did not write the code, since they just have to look at the method parameters - which can be an advantage in big classes. Another minor advantage is performance, because after compilation static methods get called with invokestatic which is slightly faster.

The public methods are still kept non static, since I don't want to discard OOP/encapsulation. I'm only talking about private static methods.

QUESTION

So what do you think of this apprach? Esp. what are the negativ sides my new habit of making all private methods static - within reason, as long as I don't need more than 3, 4 parameters?

mike
  • 4,929
  • 4
  • 40
  • 80
  • 2
    This is far too vague or broad. You are asking people to compare and contrast an OOP style with a functional programming style. Do you have a *specific* question? – Raedwald Jul 22 '14 at 11:54
  • 1
    Possible duplicate of http://stackoverflow.com/questions/538870/java-static-methods-best-practices – Raedwald Jul 22 '14 at 11:57
  • @Raedwald Thx Readwald, some answers there were useful, but I got no new insights. – mike Jul 22 '14 at 12:11
  • Personally I think that this approach will lead to somewhat ugly code. You need access to non-static parameters in the static method which you will have to pass as an argument, but the more arguments you need the uglier it becomes. Maybe you should try to just make methods static which actualy need to be static, maybe that will work out for you. – flotothemoon Jul 22 '14 at 13:00
  • It's hardly functional with `o1.someChange()` as that indicates mutation of the passed argument. You can easily make Java classes with methods that do not mutate the object or it's arguments. That is similar to a function with the object as the first argument. If you return unaltered object, a new objectm or value, then it's functional. – Sylwester Jul 22 '14 at 15:54
  • Yes, I did not fully utilitze FP. My main concern are limiting side effects, i.e. in my use case only using the method parameters. Of course this does not imply that the function result is reprocuable, because state changes may still occur. – mike Jul 22 '14 at 16:43

1 Answers1

1

IMHO You should use static methods when

  • there is no arguments (rare)
  • there is no way to extend the class of interest e.g. you want to add a method for a String.
  • you want to add a method to an interface (pre Java 8)

Otherwise a static method is much the same as an instance method where you are taking the first argument implicitly. i.e. you can simply transform one into the other.

Consider these recursive method calls.

class Type {
    static ReturnType staticMethod(Type type, Object arg) {
         return type.method(arg);
    }

    ReturnType method(Object arg) {
         return staticMethod(this, arg);
    }
}

IMHO you should use instance methods for clarity as much as possible, and leave static methods to the rare cases you have no alternative.

Note: you can use functional programming whether you use static method or not. The main principle to remember is a) always return what you create/change as a return value b) don't change any of the arguments, including this for instance methods.

This gives you the flexibility to break this a little to; only change this rather than one of the arguments (and only if you have to)

Peter Lawrey
  • 525,659
  • 79
  • 751
  • 1,130
  • I'm talking **only** about private methods, so it's useless to mention extension here. My main point is, that static method have no access to non static instance fields, which makes it easier to get an overview of what the method does, because of the limited possibilitiy of side effects. – mike Jul 22 '14 at 12:06
  • @mike I agree with the idea that you son't pass in arguments which you don't use unless you have to comply with an interface. This means you shouldn't pass in `this` if you don't need to, and in fact there is a good argument that you should extract portions of code which don't need this as it is likely they do something different. e.g. say you have an instance method, but a significant portion of code could be extracted as a static method, perhaps this is a good idea from a clarity point of view. – Peter Lawrey Jul 22 '14 at 15:04
  • I'm not aiming for code extraction or refactoring. My main goal is to reduce intrinsic choas and bring order to big classes. In my understanding, those private static helper methods - in contary to non static ones - are more incisive, reduce complexity and thus help people understand what is going on, since they don't have to consinder the class as a whole. If one passed `this`, the whole point would be obsolete, wouldn't it. – mike Jul 22 '14 at 15:37
  • @mike In my mind there is no difference between code extraction or refactoring, and structuring your code, written or yet to be written to reduce intrinsic choas and bring order to big classes. I agree that passing this to a static method is pointless, but passing this explicitly or implicitly to a method which doesn't need it is also not ideal. The question in my mind is to what extent should you encourage the use of static method when you could use either. – Peter Lawrey Jul 22 '14 at 16:12
  • 1
    In that extent in which it helps reducing coupling within the class, increases readability of a method and helps you realize how the method interacts with the classes intrinsics. At least that's my opinion, of course this approach has it's limits. E. g. it makes no sense to introduce a private static helper method with, let's say, 5+ parameters, since that would rather reduce clarity. – mike Jul 22 '14 at 16:50