The Common Reuse Principle

We’ve started learning about how to construct components, the unit of deployment. In .NET these are represented by projects that get compiled to DLL or EXE files. So far we’ve covered 2 out of 3 component cohesion principles, The Reuse/Release Equivalence Principle and The Common Closure Principle. Today we’ll look under the hood of The Common Reuse Principle.

Uncle Bob in his wonderful book ‘Clean Architecture’ defines The Common Reuse Principle (CRP) as

“Don’t force users of a component to depend on things they don’t need.”

Nowadays, I have a better understanding of what the CRP means. A few years ago, I was the technical lead on a new web API project. We were using ASP.NET WebApi2 as the framework for our new API project. My team and I were in the process of selecting an Inversion of Control (IoC) container library; a tool for inverting code dependencies. 

At the time, my favourite IoC library was StructureMap. While researching StructureMap’s feasibility for our project, I learned that it had a residual dependency on ASP.NET MVC. Given ours was a greenfields WebApi project, we didn’t need ASP.NET MVC. It felt wrong to use an IoC container dependent on technology we wouldn’t use. We didn’t know it at the time, but we were staring down the barrel of a CRP violation.

Why is this a problem?

A couple of reasons:

1. If the Microsoft ASP.NET MVC team release a new version of their component, StructureMap may need to release a new version of their library. And this would have affected us too. We would have had to recompile with the latest version of StructureMap because of changes to a component we were not using or were interested in!
2. Worse still, if for some reason ASP.NET MVC had been released with a new bug, StructureMap and our WebApi project might have been destabilised. Not much you can do if you need the functionality. However, we were not interested in experiencing problems from a dependent component we were not using.

The result was that we chose a different IoC container library. One without extra dependencies.

You may have noticed that the CRP is similar to the fourth of the SOLID Principles, the Interface Segregation Principle (ISP): “Avoid depending on modules you don’t need.”

Let’s combine the module-level (ISP) and component-level (CRP) principles into a general rule:

“Don’t depend on things you don’t need.”