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
Why Classical Singleton Is an Antipattern: How To Make It Great Again Using IOC
Classical Singleton Introduction
Classical Singleton is one of the most well-known structural patterns. It is widely used in production and is responsible for creating only one single instance. This pattern was mentioned in the GOF patterns book. How is it possible that it became an antipattern? Before we start, let's remember what a classical Singleton looks like.
Classical Singleton Implementation
Classical implementation of Singleton assumes that class contains two things:
Keep It Stupid Simple please
If you do a meta analysis on constructs such as SOLID, or any other architectural best practices, you'll easily see how there's another abstraction layer above these principles, arguably being the foundation of everything you do, which is KISS. KISS of course implies ...
Keep It Stupid Simple
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.
Seriously, OOP sux!
I have decided I will commit several murders. My first victim will be OOP, or to be specific; Your assumptions about OOP. However, don't believe me, let's ask people smarter than me, right? Some wise guy once said "You want the banana, you get the gorilla, holding a banana, in the rainforest". I can't remember who it was, but he was talking about reuse in regards to OOP. I've got 20+ years of professional experience in OO, I think I'm still quoted in regards to virtual copy constructors in a couple of the C++ drafts, and I've got almost 3 digits numbers of emails back and forth with Bjarne Stroustrup in regards to the std - Hence, I (should) know what I'm talking about, and believe me, OOP seriously sux! If you're a noob programmer, trying to grasp polymorphism, constructors, inheritance, SOLID and encapsulation - Don't worry, it's not you - It's OOP!
But don't believe me, let's go ask 1.000 random software developers who's the best software developer on this planet. 999 of those will probably answer Thorvalds Linus. So let's ask Thorvalds what he thinks about OOP. He should know, right ...?
Reading Code Is a Skill
I'm inspired to write this post because Someone Is Wrong On The Internet. Of course a more accurate statement would be "I disagree with some aspects of what someone on the internet said, even though they have an entirely valid point of view". But that's less catchy.
I saw a Tweet I agreed vehemently with, so I retweeted it:
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.
SOLID Design: The Liskov Substitution Principle (LSP)
The Liskov substitution principle is the L in the well-known SOLID acronym. The original principle definition is as follows:
Methods that use references to base classes must be able to use objects of derived classes without knowing it.
User Stories and Objects in OOP
Last year I wrote an article for InfoQ where I shared my guesses about commonalities between SOA, XP and OOP. Recently it struck me how much user stories and objects particularly have in common.
First of All, the User Story Is an Object
Just like anything else. My user story interface looks like that: