How Unit Bias can prevent us from designing a better solution

Right after establishing an overview of the system we are working on, we need to make some choices in regard to the responsibilities each class should have. This is usually the most confusing part of the overall process, because it feels like everything needs to depend on everything else. Many projects end up with large and complicated classes, or classes that have an excessive number of dependencies.

Robert C. Martin’s Single Responsibility Principle suggests that a class should have only one reason to change, in other words it should only do one thing and do it well. There is also another principle, found in the renowned Design Patterns: Elements of Reusable Object-Oriented Software (Amazon affiliate link) book, which suggests that object composition should be favored over class inheritance.

The combination of those two principles leads to a code base comprised of numerous small-sized, focused classes. Engineers that encounter such a code base for the first time usually react quite negatively. They get scared just by looking at the file structure because it seems over-complicated to them. In most cases they are not even sure how to navigate in such a system. This is exactly how Unit Bias impacts our way of thinking. Systems rearranged like that do not have more code than before; the same amount of code is simply organized in a different fashion to achieve better granularity.

In order to demonstrate Unit Bias, we will borrow an example from Mark Seemann’s blog. His son once asked him to build him a dragon using four blocks of duplos. Each duplo block’s size is equal to eight standard lego blocks. After building the first dragon, Mark tried to build another one using lego blocks this time. The exact same amount of plastic was used, yet the granularity of the second dragon was far superior.

We should not let Unit Bias prevent us from designing a better solution.

Keeping classes small and focused is key for eliminating both technical debt and numerous code smells. Systems comprised of such classes are able to evolve smoothly over time, and also accommodate for software design patterns as their natural continuation.