There are yet more code smells. Let’s keep changing the aromas. We see several symptoms and situations that make us doubt the quality of our development.
Let's look at some possible solutions.
Most of these smells are just hints of something that might be wrong. They are not rigid rules.
The part IV, and finally Part V.
Code Smell 10 — Too Many Arguments
Objects or Functions need too many arguments to work
Photo by Tobias Tullius on Unsplash
Problems
- Low maintainability
- Low Reuse
- Coupling
Solutions
- Find cohesive relations among arguments
- Create a “context”.
- Consider using a Method Object Pattern.
- Avoid “basic” Types: strings, arrays, integers, etc.
- Think on objects.
Exceptions
- Operations in real world needing not cohesive collaborators.
Sample Code
Wrong
Right
Detection
Most linters warn when the arguments list is too large.
Tags
- Primitive
Conclusion
Relate arguments and group them. Always favor real world mappings. Find in real world how to group the arguments in cohesive objects.
If a function gets too many arguments, some of them might be related to the class construction. This is a design smell too.
Code Smell 11 — Subclassification for Code Reuse
Code reuse is good. But subclassing generates a static coupling.
Photo by Brandon Green on Unsplash
Problems
- Coupling
- Maintainability
Solutions
- Favor composition.
Exceptions
- If hierarchy follows the principle behaves like then it is safe.
Sample Code
Wrong
Right
Detection
Overriding can issue warnings when subclassing concrete methods.Deep Hierarchies (more than 3 levels) are also a clue of bad subclassing.
Tags
- Composition
Conclusion
In legacy systems is very common to have Deep Hierarchies and method overriding, we need to refactor them and subclass by essential reasons and not implementative ones.
More info
Code Smell 12 — Null
Programmers use Null as different flags. It can hint an absence, an undefined value, en error etc. Multiple semantics lead to coupling and errors.
Photo by Kurt Cotoaga on Unsplash
Problems
Coupling among the callers and the senders.
Mismatch among the callers and the senders.
If/Switch/Case Polluting.
Null is not polymorphic with real objects. Hence Null Pointer Exception
Null does not exist on real world. Thus it violates Bijection Principle
Solutions
- Avoid Null.
- Use NullObject pattern to avoid ifs.
- Use Optionals.
Exceptions
- APIs, Databases and external systems where NULL does exist.
Sample Code
Wrong
Right
Detection
Most linters can show null usages and warn us.
Tags
- Null
Conclusion
Null is the billion dollar mistake. Yet, most program languages support them and libraries suggest its usage.
More info
I couldn’t resist the temptation to put in a null reference, simply because it was so easy to implement. This has led to innumerable errors, vulnerabilities, and system crashes, which have probably caused a billion dollars of pain and damage in the last forty years.
Tony Hoare
Code Smell 13 — Empty Constructors
Incomplete objects cause lots of issues.
Photo by Brett Jordan in Pexels
Problems
- Mutability
- Incomplete objects
- Concurrency inconsistencies between creation and essence setting.
- Setters
Solutions
- Pass the object’s essence on creation.
- Is it Crystal Clear for Everybody That a Date Should Not Mutate?
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) chip, bridge, engine…) without a spec. No professional engineer would even consider the idea.
Bertrand Meyer
Code Smell 14 — God Objects
An object that knows too much or does too much.
Photo by Francisco Ghisletti on Unsplash
Problems
- Cohesion
- Coupling
Solutions
- Split responsibilities.
- Follow Single Responsibility Principle.
- Follow The Boy Scout Rule.
Examples
- Libraries
Exceptions
Sample Code
Wrong
Right
Detection
Linters can count methods and warn against a threshold.
Tags
- Cohesive
Conclusion
Libraries were fine in the 60. In Object Oriented Programming we will distribute responsibilities among many objects.
Also Known as
- Large Class
More info
Code Smell 15 — Missed Preconditions
Assertions, Preconditions, Postconditions and invariants are our allies to avoid invalid objects. Avoiding them leads to errors.
Photo by Jonathan Chng on Unsplash
Problems
- Consistency
- Contract breaking
- Hard to debug
- Bad cohesion
Solutions
- Create strong preconditions
- Raise exceptions
- Fail Fast
- Defensive Programming
Examples
Constructors are an excellent first line of defense.
Anemic Objects lack these rules.
Sample Code
Wrong
Right
Detection
It’s difficult to find missing preconditions, as long with assertions and invariants.
Tags
- Consistency
Conclusion
Always be explicit on object integrity.
Turn on production assertions.
Even if it brings performance penalties.
Data and object corruption is harder to find.
Fail fast is a blessing.
More info
Relations
Code Smell 01 — Anemic Models
Writing a class without its contract would be similar to producing an engineering component (electrical circuit, VLSI (Very Large Scale Integration) chip, bridge, engine…) without a spec. No professional engineer would even consider the idea.
Bertrand Meyer
These would certainly not be the last smells.
We will keep on smelling the trash trail very soon!