Chapter 10. Interlude: Revisiting Intent

Chapter 2 discussed the topics of intentional programming and of understanding and testing the intent of code. Now that we have several chapters of testing techniques under our belts, let’s consider a more complex example.

Everywhere you look, you will find code that mixes intentions together. Most often it begins because the responsibilities have not matured enough to warrant separation. It continues when developers fail to recognize that the concerns are crystallizing. This is all about the Single Responsibility Principle, the first of Uncle Bob Martin’s SOLID principles.¹

1. SOLID stands for Single responsibility, Open-closed, Liskov substitution, Interface segregation, and Dependency inversion. See [ASD] and http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod.

Sometimes, though, we leave concerns entangled because of idiomatic inertia—we have always seen it done that way, so we continue to do it that way—or because the implementation language does not support the constructs necessary to separate them. The latter occurs often when using design patterns. While the patterns themselves do not dictate an implementation, typical implementations have evolved.

This chapter will explore this kind of entanglement using the Singleton pattern [DP]. The Singleton pattern in particular is hard to test in its canonical form, so I will look at the testing options and the tradeoffs that need to be made to test it safely and effectively. I will then look at the general issue of separating concerns.