Dependency Inversion, Polymorphism, and How to Handle Unexpected Changes in Requirements

In this article, we’ll see how to react to unexpected features and changes in requirements.

1. Overview

In our previous article, we implemented a simple FizzBuzz application while focusing on the Open-Closed Principle and testability. Additionally, we used encapsulation and immutable Divider objects to check what needs to be printed for each number.

This led to a flexible design that allowed us easily introduce new dividers (or remove the existing ones), with minimal changes to the existing code.

In this article, we’ll continue working on the same codebase. So make sure to check the current state of the application before continuing reading, if you haven’t done it already.

2. Unexpected Use-Cases

But, what if the new requirement is an unforeseen one? For instance, to print “Bar” if the number contains a “0”? Or to print “Darr” if the number has more than 4 digits?

These requirements have nothing to do with division. We have clearly not prepared for this one — therefore, at this moment, we are actually violating the Open-Closed Principle.

3. Refactor!

Don’t panic! These situations might occur. We cannot be flexible enough to protect against any change whatsoever. In fact, this can even be considered an anti-pattern, known as “over-engineering”.

Firstly, we need to refactor the existing code to conform to the Open-Closed principle again.

In our case, we can extract an interface from the divider class. This will not apply to dividers only, so we’ll need to choose a different name:

public interface HasPotentialOutput {
    boolean isApplying(int number);
    String getOutput();
}

After this, we can create another implementation of this interface, specifically for numbers containing one digit.

Though, it can be done even more generically by using lambda functions:

The predicate is a function that receives a number and it must return a boolean if the number meets its criteria.

4. Polymorhphysm

Consequently, we can easily add new custom elements that will print “Barr” if the number contains a 0 or print “Darr” if the number has more than 4 digits.

As you can see, in the list we now have various implementations of the HasPotentialOutput interface. Each of them implements the public methods in its own unique way. This pattern is also known as polymorphism.

5. Dependency Inversion

Our codebase grows bigger: it is time to add some separation.

Let’s keep FizzBuzz and HasPotentialOutput at the core of our application and consider the Dividers and CustomPotterntialElement to be the “details” that can often change (and move them to a separate package).

Without even noticing, when we introduced the HasPotentialOutput interface, we actually inverted one of the dependencies.

Now, we can clearly see that the Dividers and CustomPotterntialElement depend on the interface from the core package. In other words, the elements package depends on the core package.

As a result, the FizzBuzz object will function correctly without knowing about the various implementations and regardless of the changes in the elements.

6. Conclusion

In this article, we managed to invert the dependency from our small codebase through polymorphism.

We’ve seen how Dependency Inversion works and how it helps us to protect our core domain logic against changes in the peripheric details.