Never spread 3rd party dependencies across your application

Aleksandar Danilovic
Javarevisited
Published in
2 min readJul 19, 2022

Manage your 3rd party dependencies in the right way. Isolate code from 3rd party dependencies from the rest of the application. Write this code to be reusable. Cover this logic with appropriate JUnit tests.

Isolate code that handles 3rd party dependencies
Photo by Sofiya Levchenko on Unsplash

When you have 3rd party dependencies, you have to use them in the right way. The typical and wrong way is to use classes from that 3rd party dependency all across your application.

While maybe it can look fine in the beginning because of the speed of implementation, later you will pay price. As everything in this world changes, your 3rd party dependency will also evolve, and your current version will be obsolete. Then you should change it to the new version. Changes could be well enough to force you to rewrite some code.

Then you should do it in many places in your application. And of course, you could break something. You will be forced to do a lot of regression testing. Migration to a new version of your 3rd party dependency will be a big pain!

Let me tell you about the example from my own experience. In one company I have the task to migrate Apache HTTP Client library from version 4 to version 5. They used this library for implementing REST calls to more than 20 different APIs.

Each API has a bunch of different endpoints. There were more than 100 different endpoints overall. Unfortunately, they didn’t make common code for accessing 3rd party API endpoints, but each method had its own code again and again.

A lot of copy-paste code in many places. You can imagine how this migration was hard! You should change the code in all these places. Because there were differences between Apache HTTP Client libraries 4 and 5, each change required regression testing in order to not break something.

Moreover, mainly there weren’t any automatic integration tests to make this migration easier (in order to not break contracts between API parties). In the end, it was a very time-consuming and error-prone process!

Conclusion

Isolate code from 3rd party dependencies into its own service layer. Don’t spread code from 3rd party dependencies throughout your application. Write reusable code that is covered with JUnit and integration tests. It will pay you in the end!

--

--

Aleksandar Danilovic
Javarevisited

Work as Senior Java developer for 16 years. Publish stories about Java, algorithms, object oriented design, system design and programmers' life styles