Common advice when analyzing or improving the structural quality of a system is to aim for a separation of concerns in order to create loosely coupled, highly cohesive code. In this post we will discuss the first C of structural quality: the separation of concerns. What does it mean, how does it contribute to structural quality and how can we apply it to our code?

Object-oriented software development remains a subject of debate. Some say object orientation is a thing of the past; too ceremonious and unpractical for real use. Although I recognize that some overly dogmatic approaches have muddied the waters, I think object orientation remains a useful way of thinking about and designing software, also when supplemented with other paradigms.

In this post, we will dive into the building blocks of object orientation to better understand what it is, the instruments it offers and how we can use these instruments to design maintainable software.

Testing software, whether as specification beforehand or as verification afterwards, is often based on examples. Examples are easy to understand, explain the language of the domain and help illustrate the intended use of the system or unit under test.

However, it can be difficult to fully test a system or unit using examples alone. Coverage alone is not enough. When there are lots of cases that need consideration, there is a risk that edge-cases and certain combinations of inputs are overlooked. In some cases, the sheer amount of possible inputs and outputs make total testing a prohibitive effort.

That is where property-based testing can offer a helping hand. In this post, we will look at the similarities and differences between example-based and property-based approaches to testing and why there is value in combining both. All this against the backdrop of a relatively simple game: Rock, Paper, Scissors.

In lectures regarding object-oriented programming, I sometimes encounter students questioning the use of Java’s interfaces. Why do we need to go through the hassle of defining a class as well as an interface? Once they are convinced (or conditioned) to use them, the questions do not end: students often wonder when interfaces are and are not necessary and how they can contribute to well-designed software.

In this post, we will uncover the power of protocols, a more general term for interfaces, and dive into some common implementations. Along the way, we will discuss why interfaces are useful and how they are commonly used to shape the design and architecture of (object-oriented) software.

One of the primary objectives when designing software is to strive for simplicity. We are reminded of this through acronyms, adagia and our failure to easily comprehend our colleagues' — or, perhaps more often, our own — code. But what does it mean to “Keep It Simple, Stupid”? And when is software too complex?

In this post, we will explore complexity from the perspective of execution flow in our code. We will have a look at a formal, rigorous method of assessing this complexity and, even though these measures are not novel, they are still worth knowing (and trying out) when striving for quality software.