Simplicity is the ultimate sophistication. [Leonardo Da Vinci]
Today the topic is simplicity: let’s deep dive into the 4 elements of simple design; also referred to as “rules”, these 4 elements came from the mind of Kent Beck while he was developing the concepts of Extreme Programming.
The 4 rules are:
It’s important to explicit that the order is not random, rather it expresses a priority: for example, passing tests is more important than minimizing duplication.
Now, the question is: does this order make sense? …
Open to extensions closed to changes: let’s delve into the Open-Closed principle, one of the 5 SOLID principles.
The SOLID principles are the “first five principles” of Object-Oriented software development described by Robert C. Martin. The word is an acronym coined by Michael C Feathers that serves as a reminder of these principles.
Here, specifically, I want to write about the second principle, the Open/Closed.
This principle states that a module should be closed to modifications and open to extensions; closed because those who use it should not be impacted by any changes in which they have no interest, open…
Composition over inheritance.
How many times have you read and heard this? I think it’s the web’s most clickbait topic about Object-Oriented Programming.
Today it’s my turn to talk about it because I’ve always struggled to understand what it meant and I think we often use examples that are too complex while the concept is powerful yet simple!
First of all, I’ll try to explain the problem that Composition solves: inheritance is often used inappropriately, with the only goal to avoid code duplication.
DRY is definitely a good principle, but this is not the purpose of Inheritance, which instead aims…
All it takes is an IF
How many times have you heard this? You also know that adding IF without thinking is a failed strategy for the maintenance of our code; today we look for a possible alternative among the Design Patterns.
Design Patterns are a series of abstractions that aim to be solutions to certain problems; they are not “out of the box” solutions but more something to adapt to our context and our situation.
Among the design patterns, there are various options that we can use to replace IFs in our codebase, replacing them with a design that…
We’ve all had to deal with legacy code that had various design issues and wasn’t covered by tests. What to do in these situations?
First of all, let’s agree on definitions: with “legacy code” I mean any code that is not covered by automated testing, as suggested by Michael C. Feathers in his book: Working Effectively With Legacy Code.
When dealing with legacy code, the biggest mistake we can make is to accept the status quo and forgo automated testing. I dedicated a video to this topic on my Youtube channel (in Italian), where I presented a list of what…
Functions that modify the state should not return any value, and functions that return the state or part of it should not be able to modify it.
The Command-Query Separation principle explains that the abstraction of a software interface should be designed with only two types of methods:
The one you are about to read is my favourite quote.
It struck me from the first moment I heard it; you can also find it as a “mantra” in the description page of my site, in fact; this is because I believe it’s a phrase that marked a turning point for me.
I’m not a great programmer. I’m just a good programmer with great habits.
Boom. Powerful. Powerful, almost revelatory, at least for me.
There was a long period of my life in which I lived with the feeling that certain topics regarding Software Design were light years away…
The wise man says:
Prevention is better than cure and, among the various problems, even better is to prevent first those that in the long run can generate new problems.
The code smells are one of the main concepts of object-oriented programming; in particular, in this piece, I want to talk about the three “original sins”.
In addition to the classic duplication, there are three smells that should be highlighted over the others because they are the most dangerous; the reason? with time they become the cause of new smells.
I’m talking about Primitive Obsession, Feature Envy and Message Chains.
In an environment in which we work in Trunk-based development, how can we manage workflows without breaking existing code?
Trunk-based development is a practice that opposes the more classic Feature Branch practice for new feature development: in this working methodology, all commits are made directly on master.
As you can imagine, this solves problems typical of creating and maintaining feature branches, but it also poses a number of new different issues to keep in mind during the work.
Once the first release of the application is reached, committing to master means to send the changes together in the main branch…
Leonardo Da Vinci said:
Simplicity is the greatest sophistication.
Today we discover a chart that helps us embrace simplicity as a tool, particularly while doing Test Driven Development.
T. P. P. means Transformation Priority Premise. A high-sounding name but not very explanatory. To explain what this technique is for, we need a little context.
We talked about Test Driven Development; if you know this technique, whether you’re an expert or you’ve just started using it, there’s one aspect you might have noticed: during the green phase, in which we go to make green the test we’ve written implementing the minimum…