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 […]
Kategoriarkiv: Clean Code
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 […]
The Common Reuse Principle
What? The Common Reuse Principle (CRP) states: ”The classes in a component are reused together. If you reuse one of the classes in a component, you reuse them all.” In the last post I wrote about the Reuse/Release Equivalence Principle (REP). It says that reusable components must be releasable components, with everything that comes with […]
The Reuse/Release Equivalence Principle
What? When we group classes into components we strive towards making some of them reusable so that we can potentially use them for other purposes and also other teams in the organization may use them if they want to. The Reuse/Release Equivalence Principle (REP) states that ”The granule of reuse is the granule of release”. […]
Principles of Package and Component Design
One of the most known set of principles regarding software design is probably SOLID. But an important part of structuring software that SOLID does not cover is how to group classes into packages and components in a way that makes it scale, both when the application itself grows but also when the number of teams […]
SOLID – The Dependency-Inversion Principle
We have now reached the grande finale of the blog series on SOLID, the big D, The Dependency-Inversion Principle. Let’s jump right into it. Definition The Dependency Inversion Principle (DIP) states: A: High-level modules should not depend on low-level modules. Both should depend on abstractions. B: Abstractions should not depend upon details. Details should depend […]