Each Private Static Method Is a Candidate for a New Class

@misc{bugayenko2017blog0207,
  author = {Bugayenko, Yegor},
  title = {{Each Private Static Method Is a Candidate for a New Class}},
  howpublished = {\url{https://www.yegor256.com/170207.html}},
  year = {2017},
  month = {feb},
  note = {[Online; accessed 26-10-2024]}
}

Do you have private static methods that help you break your algorithms down into smaller parts? I do. Every time I write a new method, I realize that it can be a new class instead. Of course, I don’t make classes out of all of them, but that has to be the goal. Private static methods are not reusable, while classes are—that is the main difference between them, and it is crucial.

Here is an example of a simple class:

class Token {
  private String key;
  private String secret;
  String encoded() {
    return "key="
      + URLEncoder.encode(key, "UTF-8")
      + "&secret="
      + URLEncoder.encode(secret, "UTF-8");
  }
}

There is an obvious code duplication, right? The easiest way to resolve it is to introduce a private static method:

class Token {
  private String key;
  private String secret;
  String encoded() {
    return "key="
      + Token.encoded(key)
      + "&secret="
      + Token.encoded(secret);
  }
  private static String encoded(String text) {
    return URLEncoder.encode(text, "UTF-8");
  }
}

Looks much better now. But what will happen if we have another class that needs the exact same functionality? We will have to copy and paste this private static method encoded() into it, right?

A better alternative would be to introduce a new class Encoded that implements the functionality we want to share:

class Encoded {
  private final String raw;
  @Override
  public String toString() {
    return URLEncoder.encode(this.raw, "UTF-8");
  }
}

And then:

class Token {
  private String key;
  private String secret;
  String encoded() {
    return "key="
      + new Encoded(key)
      + "&secret="
      + new Encoded(secret);
  }
}

Now this functionality is 1) reusable, and 2) testable. We can easily use this class Encoded in many other places, and we can create a unit test for it. We were not able to do that with the private static method before.

See the point? The rule of thumb I’ve already figured for myself is that each private static method is a perfect candidate for a new class. That’s why we don’t have them at all in EO.

By the way, public static methods are a different story. They are also evil, but for different reasons.

P.S. Now I think that the reasons in this article are applicable to all private methods, not only static ones.

In OOP, private static methods are...

— Yegor Bugayenko (@yegor256) October 18, 2020