When you design a class you should never design it in a way that the class itself knows how it is used from the outside. Breaking this principle will make it difficult for other developers providing other implementations. I recently stumbled upon an implementation of different entities where the implementation had to provide a unique id for itself. Why this is causing problems and how you better design such a situation I’ll explain in this post.
Let’s introduce an example of the problem that I want to talk about. There is an interface called
Entity that specifies a method
getId() that needs to provide a unique id.
We also have an implementation called
House of this interface:
Another implementation might be a
You can already imagine the problem that’s present here. We can easily have a violation of the contract of an
Entity. As soon as one of the addresses of the
PostCard is empty we can end up with a
House that returns the same id and this is against the contract of an
So without knowing all implementations of the
Entity you can never be sure if you actually provide a unique Id or not. This problem gets worse, the more implementations you have.
Another problem is that you are never able to write a unit test that can actually test the requirement that the id is unique over the whole application.
The underlying problem here is that we put the responsibility to provide unique ids to the wrong layer in our application. The only instance that can control, and ensure, that we have unique ids is the class that creates the entities in our application. And if we don’t have such a class yet than we need to provide a factory for that.
We can easily test that
idGenerator.next() always provides a unique id. And with restricted visibility of the constructor we can ensure that you can’t create a