-
Spaceship simplifications
I ended the last post by stating that I would provide an example of how you can implement the new C++ spaceship operator for your own class. In this post I will show you how that can be done and how it can simplify your implementation a lot. Assume that you have defined your own […]
-
Hidden conditions
One way of making code easy to understand and reason about is to try to ensure that it does exactly what you expect it to do. Sometimes however, there are conditions secretly hidden in places of the code that leaves you scratching your head and forces you into a quest for answers down the deepest […]
-
The art of keeping things simple
As a software developer you go through different phases in your personal development. Many, but far from all, end up valuing simple code. Simple does not imply that the code doesn’t do what it needs to do, it means that the code is written in a way that puts minimal cognitive load on the human […]
-
Representing missing value in C++
One thing that I have bothered me quite a lot when coding in C# is a good way to indicate the absence of a value. There are a few different alternatives how this can be done, the most common being using null. However, using null instead of an actual type quite often leads to crashes […]
-
Nullable reference types compared to the Option monad
I wanted to investigate how Nullable reference types, the new big feature that was introduced in C# 8, compared to the Option type from language-ext. But let’s start with some information to set up the scene. Nullable reference types The way to indicate the abscence of a value in C#, as well as in many […]
-
A functional approach to error handling in C#
Imagine that you want to write a simple console application that queries the user for two integers, divides the first integer with the second, and writes the result to the console window. What can go wrong in a simple program like this? The first thing that comes to mind is probably that the user might […]
-
The Stable-Abstractions Principle
What? This is the last of the Principles of Package and Component Design, the Stable-Abstractions Principle (SAP). It says: ”A component should be as abstract as it is stable.” In the Stable-Dependencies Principle (SDP) post we learned that stability, or in that case Instability, I, can be calculated using the formula I = Ce / […]
-
The Stable-Dependencies Principle
What? The Stable-Dependencies Principle (SDP) says: ”Depend in the direction of stability.” What this means is that the direction of the dependencies in the component dependency graph should point towards more stable components. To understand what this means we need to define stability for a component. Uncle Bob turns this around and defines a way […]
-
The Acyclic Dependencies Principle
What? The Acyclic Dependencies Principle (ADP) is the first of three principles that deals with the relationships between components. It says: ”Allow no cycles in the component dependency graph.” If you draw the components and the dependencies between them and you are able to follow a dependency back to a component you have already visited, […]
-
The Common Closure Principle
What? The Common Closure Principle (CCP) states: ”The classes in a component should be closed together against the same kind of changes. A change that affects a component affects all the classes in that component and no other components.” To put it in other words, a component should not have multiple reasons to change. This […]