Branch of abstraction pattern

A few days ago, I wrote a post about the Strangler Fig pattern designed to securely exclude some functionalities from one system to another. I mentioned that when you have a use case where you are changing calls within one system, you must alter all calls and redirect them to your new code.

The branch of abstraction pattern is designed to help you with this concrete problem - changing calls within one system from old implementation to the new one. Just like Strangler Fig, it enables implementation changes in a safe, iteration way and consists of five simple steps.
It’s worth mentioning Martin Fowler was writing about it on his blog.

This step involves identifying the functionality you want to redirect and adding appropriate abstraction. In Java, you should just add an interface covering your old call.

In this step, you must implement your new abstraction in an old class, which does the job and change the field type from the old class-specific type to your new abstraction within a system.

These days, we are smarter than years ago, and it seems obvious that abstractions are key, so probably you can already have this abstraction in your system.

Now, when we have good abstraction under our functionality and know it is working fine, we can write the new implementation. A good point is to leave the old implementation working on production and test the new one, for example in unit/integration tests.

The penultimate step is to switch to the new implementation on production. You can do it, for example, via a feature toggle or whatever you are using in your system.

This is the time when you should carefully observe if any errors appear. If yes, you can go back to the old implementation very fast and try to fix bugs in the new implementation.

If not, you can go to the step number five.

It is the time when you can clean your code from old implementation. It is a good point to leave our new abstraction because it has a low impact on the readability of the codebase and can be helpful in the future.

Don’t be scared to remove old code with specific tests. This is why we have version control systems (you are using git, right? RIGHT?) so that in the event of problems, we can quickly restore deleted code.