I want to talk about fatal logging. It’s practically always a bad idea. Let me explain…
I was recently reviewing some code written in Go, where I saw this pattern in a constructor function:
The Dangers of Fatal Logging
Solid Design Principles Review
In this article series, we will examine SOLID Design Principles: what are they, and what are they meant to do?
First of all, we will look at the brief history behind the principles; later on, we will see why it is so important to use SOLID principles in our day-day designs, and then finally we will dive into the details of the principles.
SOLID code, the Silver Bullet
SOLID is one of those words we developers throw around us, implying some deeper meaning, hopefully helping us to create better software systems. It should be second hand nature to all (OO) developers, but unfortunately is often misunderstood, or used to defend a decision, based upon flawed logic. Hence, in this article, I will try to "dumb it down" and use analogies for each of its 5 items, in an attempt at making it more easily understood, to avoid confusion.
Single Responsibility Principle
The "S" I'm solid implies that each class should only do one thing. It often helps to break down your flow into verbs to make sure you follow this principle. For instance, imagine you have a task scheduler, that should implement the ability to create tasks for execution at some point into the future. Maybe you want it to have the ability to persist tasks, in case the process is recycled, without dropping tasks. Imagine Hangfire here as an example. Well, ask yourself how many verbs you have in the above feature requirement, and then try to group them into related actions. I could find the following.