Why the first instruction we learn to program should be the last to use.
Nobody uses GOTO instruction anymore and few programming languages still support it.
We have matured and confirmed spaghetti code is unmaintainable and error prone. Structured Programming solved that problem years ago.
We got rid of the sentence thanks to Edsger Dijkstra’s incredible paper: Go To Statement Considered Harmful.
Next evolution step will be removing most IF statements
IFs/Cases and Switches are GOTOs disguised as structured flow.
Our tool will be Object Oriented Programming principles.
Incomplete objects cause lots of issues.
Problems
- Mutability
- Incomplete objects
- Concurrency inconsistencies between creation and essence setting.
- Setters
Solutions
- Pass the object’s essence on creation
Examples
- Some persistence frameworks in static typed languages require an empty constructor.
Exceptions
- Stateless objects. Always better solution than static class methods.
Sample Code
Wrong
Right
Detection
Any linter can warn this (possible) situation.
Tags
- Essence
- Incomplete
- Mutable
Conclusion
Always create complete objects. Make their essence immutable to endure through time. Every object needs its essence to be a valid one since inception.
Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration)…
The code smells bad. Let’s see how to change the aromas.
In this serie we will see several symptoms and situations that make us doubt the quality of our developments.
We will present possible solutions.
Most of these smells are just clues of something that might be wrong. They are not rigid rules.
Code Smells
Your objects are a bunch of public attributes without behavior.
Protocol is empty (with setters/getters).
If we ask a domain expert to describe an entity he/she would hardly tell it is ‘a bunch of attributes’.
Problems
Solutions
1) Find Responsibilities.
2) Protect your attributes.
3) Hide implementations.
4) Delegate
Examples
- DTOs
Sample Code
Wrong
Right
Detection
Detection can be automated with sophisticated linters ignoring setters and getters and counting real behavior methods.
Also Known as
- Data Class
Tags
- Anemic
- OOP as Data
- Encapsulation
- Setters/Getters
- Mutability
More info
This…
Let’s break Demeter’s Law.
Problems
- Unnecessary Indirection
- Empty Classes
- Readability
Solutions
1. Remove Middle man.
Sample Code
Wrong
Right
Detection
Same as its opposite smell, We can detect this small using parsing trees.
Tags
- Coupling
- Declarative
- Readability
Conclusion
This is exactly the opposite to Message Chain. We make explicit the message chain.
Relations
More info
Whenever I have to think to understand what the code is doing, I ask myself if I can refactor the code to make that understanding more immediately apparent.
Martin Fowler
This article is part of the CodeSmell Series.
Nice article and nice explanation of TDD
But it has a severe misconception since the title
TDD has nothing to do with testing.
TDD is about developing. It is a software developing technique.
Testing is another activity
Say it only once
Problems
- Bad Responsibilities Assignments
- Code Duplication
- Maintainability
- Single Responsibility Violation.
- Copy-pasted code.
Solutions
- Refactor
Sample Code
Wrong
Right
Detection
Some modern linters can detect repeated patterns (not just repeated code) and also while performing our code reviews we can easily detect this problem and ask for a refactor.
Tags
- Code Duplication
Conclusion
Adding a new feature should be straightforward it our model maps 1:1 to real world and our responsibilities are in the correct places. We should be alert for small changes spanning in several classes.
More info
Duplication is the primary enemy of a well-designed system.
Robert Martin
This article is part of the CodeSmell Series.
Names should always indicate role.
Problems
- Declarative
- Design for Change
- Coupling to accidental implementation
Solutions
1. Rename your variable according to the role.
Sample Code
Wrong
Right
Detection
This is a semantic rule. We can instruct our linters to warn us from using names related to existing classes, types o reserved words since they are too implementative.
Tags
- Declarative
Conclusion
The first name we can across is related to an accidental point of view. It takes time to build a theory on the models we are building using our MAPPERS. Once we get there, we must rename our variables-
Relations
More info
Credits
This idea came from this tweet
Types are essentially assertions about a…
Two classes entangled in love.
Problems
- Coupling
- Bad Responsibilities Assignments
- Bad Cohesion
- Class Interfaces too Public
- Maintainability
- Extensibility
Solutions
- Refactor
- Merge
- Replace Hierarchy With Delegation.
Sample Code
Wrong
Right
Detection
Some linters graph class relations and protocol dependency. Analyzing the collaboration graph we can infer rules and hints.
Tags
- Coupling
Conclusion
It two classes are too related and don’t talk much to others we might need to split, merge or refactor them, Classes should know as little about each other as possible.
Relations
More info
No matter how slow you are writing clean code, you will always be slower if you make a mess.
Robert Martin
This article is part of the CodeSmell Series.
If your method is jealous and don’t trust in delegation you should start to do it.
Problems
- Coupling
- Low Reuse
- Low Testability
- Bad Responsibilities Assignment
- Bijection Fault
Solutions
- Move method to the appropriate class.
Sample Code
Wrong
Right
Detection
Some linters can detect a sequential pattern of collaborations with another object.
Tags
- Coupling
Conclusion
- We should assign responsibilities according to real object mappers and avoid abusing other objects protocol.
Relations
More info
We argue that design practices which take a data-driven approach fail to maximize encapsulation because they focus too quickly on the implementation of objects. We propose an alternative object-oriented design method which takes a responsibility-driven approach.
This article is part of the CodeSmell Series…
Maximiliano Contieri
I’m senior software engineer specialized in declarative designs. S.O.L.I.D. and agile methodologies fan.
