Seeking code quality
This week, during another refactoring session, I had the idea that every time I come across code that needs to be modified to conform to one of the principles of best practices for software development, I’ll modify it and share the solution through this blog, exploring its drawbacks, benefits gained by conforming to the principle and also providing a brief explanation of it. Starting now with the OCP - Open-Closed Principle.
The Open-Closed Principle
This principle is the foundation for building code that is maintainable and reusable. Modules that conform to this principle are, at the same time, “open for extension”, so that they can behave in different ways, as the requirements of the application are modified or as new ones are added. And “closed for modification”, which means that the module implementation cannot be violated, nobody can modify its source code.
The description above may seem quite contradictory, since to extend a module functionality, a code modification needs to be done. Therefore, we deduce that a functionality that cannot be modified is given as fixed. How could we deal with this conflict? The best way is to show it up through an example.
In my current project, there’s a task manager module, which is responsible for executing asynchronous tasks queued up by its clients. Basically it iterates over all the elements in a pending tasks list and executes each of them, respecting the order they appear. The excerpt below shows how this class was implemented, it’s a bit different from the original version, making it easier to understand.
The method executePendingTasks() doesn’t conform to the Open-Closed Principle, because it cannot be closed against new task implementations. If your client suddenly comes up, asking you to extend the task manager module, to start handling a new task — this is always happening and since we’re all agile, we’re ready to handle it eh? — so this method will always have to be modified to support a new task. This can be easily done by inserting a new case statement, but it’s far from an elegant solution.
Unfortunately most of developers follow this approach, the easier one (seemingly), specially when dealing with legacy code, when the solution is already “thought”. All they have to do is follow the way the implementation has been done, not assessing it. Eventually, the code ends up with a huge number of lines (eighteen case statements in my case) and at that time, luckily, maybe a sensible developer will realize the code oddity and will try to improve its quality.
In the following excerpt, I’m showing the solution I gave to the problem, conforming to the OCP. Summarizing, the Task class is now abstract and I included an abstract method called execute(). Following this approach, ALL new tasks being created will be derivatives of this abstract class, providing their implementations of the execute() method.
And from now on, to our task manager, executing the pending tasks has became much easier. All it has to do is go through each of them and invoke their execute() method, resulting a cleaner, decoupled and non-intrusive code.
Now if we want to extend executePendingTasks() to start executing any other new task, all we need to do is create a new derivative of the Task class. This method is now conforming to the Open-Closed Principle. Its behaviour can be extended but its implementation doesn’t change.