Enhancing Testability and Maintainability Through SOLID Principle

In this lesson, we’ll review a design approach known as the hexagonal architecture, based on the SOLID principles we already know. Using this approach allows us to use TDD more effectively across more of our code base.

Implementing SOLID principles

We learned that the Dependency Inversion Principle helps us isolate some code we want to test from the details of its collaborators. We noted that was useful for testing things that connected to external systems that were outside of our control. We saw how the single responsibility principle guided us into splitting up software into smaller, more focused tasks.

Applying these ideas to our earlier sales reporting example, we would arrive at an improved design, as shown in the following illustration:

The preceding illustration shows how we’ve applied SOLID principles to splitting up our sales report code. We’ve used the single responsibility principle to break down the overall task into three separate tasks:

• Formatting the report.

• Calculating the sales total.

• Reading the sales data from the database.

This already makes the application a little easier to work with. More importantly, we’ve isolated the code that calculates the sales total from both the user and the database.

Note: This calculation no longer directly accesses the database. It goes through another piece of code responsible for doing only that. Likewise, the calculation result isn’t directly formatted and sent to the user. Another piece of code is responsible for that.

Flexibility with dependency inversion

We can apply the Dependency Inversion Principle here as well. By inverting the dependencies on the formatting and database access code, our calculated sales total is now free from knowing any of their details. We’ve made a significant breakthrough:

• The calculation code is now fully isolated from the database and formatting.

• We can swap in any piece of code that can access any database.

• We can swap in any piece of code that can format a report.

• We can use test doubles in place of the formatting and database access code.

Versatility and testability

The biggest benefit is that we can swap in any piece of code that can access any database, without changing the calculation code. For example, we could change from a Postgres SQL database to a Mongo NoSQL database without changing the calculation code. We can use a test double for the database so ...