DEV Community: Henri Tremblay

Pragmatism applied: Avoid single implementation interface

Henri Tremblay — Tue, 20 Aug 2019 13:33:20 +0000

A long time ago (think 2000), all classes in Java used to have an interface.
You first started with MyInterface then added a MyInterfaceImpl.

This caused a lot of boilerplating and debugging annoyance.
I used to have code generator to make it easier.

Why were we doing that?

Two reasons. A bad and a good one.

The bad reason is decoupling

The idea was that if you depend on an interface you can swap the implementation if ever needed.

This is a "you might need it later" issue.
Every sentence with "might" and "later" in it should be rephrased as "I don't care".
Because most of the time, "later" never occurs and you are just wasting time an energy right now just in case.
Whatever happens later should be dealt with later.

That said, you might argue that "yes, but it will be much more painful to deal with it later".
Ok. Let's check.

Let's say you have some cheese

public class Cheese {

  private final String name;

  public Cheese(String name) {
    this.name = Objects.requireNonNull(name);
  }

  public String getName() {
    return name;
  }
}

Then you want to retrieve the cheese from a database.

public class CheeseDao {

  private final Database database;

  public Cheese findByName(String name) {
    return database.names()
        .filter(name::equals)
        .reduce((a, b) -> {
          throw new IllegalStateException("More than one entry found for " + name);
        })
        .map(Cheese::new)
        .orElse(null);
  }
}

And then you have a REST resource depending on the CheeseDAO.

public class CheeseResource {

  private final CheeseDAO cheeseDAO;

  public CheeseResource(CheeseDAO cheeseDAO) {
    this.cheeseDAO = cheeseDAO;
  }

  public Cheese get(String name) {
    return cheeseDAO.findByName(name);
  }
}

Since you are an efficient human being, you decided that no interface was needed for the CheeseDAO.
It has only one implementation so far and you have not building a cheese open source library.
All this code is into your little cheese application.

But one day, some requirements arrive and you actually do need another implementation.
"Later" actually happened.

So you now turn CheeseDAO into an interface.

public interface CheeseDao {
  Cheese findByName(String name);
}

public class CheeseDatabaseDao implements CheeseDao {

  private final Database database;

  public Cheese findByName(String name) {
    return database.names()
        .filter(name::equals)
        .reduce((a, b) -> {
          throw new IllegalStateException("More than one entry found for " + name);
        })
        .map(Cheese::new)
        .orElse(null);
  }
}

And now, off you go to fix compilation errors on all the classes depending on CheeseDAO.

For instance, you modify CheeseResource to this:

public class CheeseResource {

  private final CheeseDAO cheeseDAO;

  public CheeseResource(CheeseDAO cheeseDAO) {
    this.cheeseDAO = cheeseDAO;
  }

  public Cheese get(String name) {
    return cheeseDAO.findByName(name);
  }
}

I'll leave you 5 seconds. 1, 2, 3, 4, 5.

Yes, I'm messing with you.
Nothing has changed.
Not a single character.

Turning a class into an interface "later" wasn't painful after all.

Which is why I call it a bad reason.
Doing it is painful now and has no benefit later.

Now, the good reason: Testing

The problem with a concrete class is that you need to instantiate.
In a testing context, you want to mock dependencies.
In order to mock a concrete class, you need two things

Extend the class to be able to mock the behavior
Instantiate the class

The first requirement is easy, the second is trickier.
If the class is simple and has a simple constructor to call, everything is alright.
If the class is quite annoying to instantiate, you have a problem.

This is where I step in.
The coolest trick would be to instantiate the class without calling any constructor.

Fortunately, Java allows that.
Because serialization does it all the time.
You just need to sneak under the hood a little.

Originally, I got involved in open source to solve that problem specifically.
Most mocking framework today are using Objenesis to perform this task.
I talked a bit about it in a previous post.

So, since 2003, you don't need to be afraid to use concrete classes as dependencies.
You can mock them just as any interface.

Map best practices

Henri Tremblay — Tue, 20 Aug 2019 03:38:28 +0000

Today’s topic is about Map and misuses I’ve seen during many code reviews.

The idea with a Map is to do whatever you need by doing as less hashing as possible.
A hash occurs each time you access the Map (e.g. get, containsKey, put).

In Java 8, some useful new methods were added.
Let’s say you want to check if something is in a Map:

If it is, return it
If it’s not, add it and return it

The classical way to do it is:

if (map.containsKey(key)) { // one hash
    return map.get(key); // two hash
}
List<String> list = new ArrayList<>();
map.put(key, list); // three hash
return list;

It is also the slowest.
A better way is:

List<String> list = map.get(key); // one hash
if(list == null) {
    list = new ArrayList<>();
    map.put(key, list); // two hash
}
return list;

This is already much better. You save one hash.

Important: This isn’t valid if the value might be null.
But I highly recommend you to never have null values

But since Java 8, you have three better solutions.

The first one is:

map.putIfAbsent(key, new ArrayList<>()); // one hash
return map.get(key); // two hash

It is better but not much. You still have two hashes.
And the ArrayList is instantiated even if it is already in the map.

You can improve with the longer:

List<String> list = new ArrayList<>();
List<String> result = map.putIfAbsent(key, list); // one hash only!
if(result == null) {
    return list;
}
return result;

Now we’re talking, only one hash! But still the ArrayList is instantiated uselessly.

Which brings us to another Java 8 method that does the trick.

return map.computeIfAbsent(key, unused -> new ArrayList<>()); // one hash only!

Job done.
One line and the fastest we can get.
The ArrayList will be instantiated only when needed.

Important: Do not do map.computeIfAbsent(key, ArrayList::new).
computeIfAbsent takes a Function<KEY, VALUE> in parameter.
So this will in general not compile unless the KEY matches the parameter of one of the ArrayList constructors.
An example is when the KEY is an Integer.
Passing a constructor method reference will actually call new ArrayList(KEY)… which is obviously not what you want.

In order to convince you that it's the best solution, I have made a little benchmark using JMH.
Here are the results:

Benchmark                               Mode  Cnt         Score        Error  Units
MapBenchmark.computeIfAbsent_there     thrpt   40  25134018.341 ± 687925.885  ops/s (the best!)
MapBenchmark.containsPut_there         thrpt   40  21459978.028 ± 401003.399  ops/s
MapBenchmark.getPut_there              thrpt   40  24268773.005 ± 690893.070  ops/s
MapBenchmark.putIfAbsentGet_there      thrpt   40  18230032.343 ± 238803.546  ops/s
MapBenchmark.putIfAbsent_there         thrpt   40  20579085.677 ± 527246.125  ops/s

MapBenchmark.computeIfAbsent_notThere  thrpt   40   8229212.547 ± 341295.641  ops/s (the best!)
MapBenchmark.containsPut_notThere      thrpt   40   6996790.450 ± 191176.603  ops/s
MapBenchmark.getPut_notThere           thrpt   40   8009163.041 ± 288765.384  ops/s
MapBenchmark.putIfAbsentGet_notThere   thrpt   40   6212712.165 ± 333023.068  ops/s
MapBenchmark.putIfAbsent_notThere      thrpt   40   7227880.072 ± 289581.816  ops/s

Til next time: Happy mapping.