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) chip, bridge, engine…) without a spec. …

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

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

• No Encapsulation.
• No mapping to real world entities.
• Duplicate Code
• Coupling

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

• Wikipedia
• Refactoring Guru
• Nude Models — Part I : Setters
• Nude Models — Part II : Getters
• How to Decouple a Legacy System

This article is part of the CodeSmell Series. …

Problems

• Readability
• Bad Naming
• Low Cohesion
• Single Responsibility Principle

Solutions

1. Use good object wrappers
2. Use dynamic decorators

Sample Code

Wrong

Right

Detection

We can instruct our static linters to find wrapping methods if they follow conventions like doXXX(), basicXX() etc.

Tags

• Declarativeness

Conclusion

We came across this kind of methods some time in our developer life, We smelled something was not OK with them. Now is the time to change them!

More info

The primary disadvantage of Wrap Method is that it can lead to poor names. …

Searching for a concrete method implementation? Go back and forth, up and down.

Problems

• Deep Hierarchies
• Subclassification for Code Reuse
• Readability
• Low Cohesion
• High Coupling

Solutions

1. Favor composition over inheritance.
2. Refactor deep hierarchies.

Sample Code

Wrong

Right

Detection

Any linter can check for suspects against a max depth threshold.

Tags

• Hierarchy

Conclusion

Many novice programmers reuse code through hierarchies. This brings high coupled and low cohesive hierarchies.

Johnson and Foote established in their paper this was actually a good design recipe back in 1988. We have learned a lot from there.

We must refactor and flatten those classes.

Relations

More info

https://wiki.c2.com/?DeepClassHierarchies

Hierarchies should be deep by Johnson and Foote

An error arises from treating object variables (instance variables) as if they were data attributes and then creating your hierarchy based on shared attributes. …

Problems

• Readability
• Maintanability

Solutions

1. Keep just one working version of your artifact (class, method, attribute).
2. Leave time control to your version control system.

Sample Code

Wrong

Right

Detection

We can add automatic rules to find versioned methods with patterns.

Like many other patters we might create an internal policy and communicate.

Tags

• Versioning

Conclusion

Time and code evolution management is always present in software development. Luckily nowadays we have mature tools to address this problem.

Relations

Original idea

That’s why I write, because life never works except in retrospect. You can’t control life, at least you can control your version.

Chuck Palahniuk

This article is part of the CodeSmell Series. …

“Hello World” is the first program me make in every language.

We can measure the complexity of language by counting the lines it takes to produce the desired output.

We can also time how much does it take to a newbie to figure out the solution (this is also known as Time to hello world” (TTHW).

These two metrics are uncorrelated to productivity.

Many sites compile different Hello World programs in a lot of languages.

The Problems

The Hello Word example has a lot of problems introduced early when developers are making their first steps in programming.

1. It uses globals in many languages. Global functions are a code smell. Teaching them to newcomers in theirs first example is conflicting. …

We want our code to behave different on different environments, operating systems, so taking decisions at compile time is the best decision, isn’t it?.

Problems

• Readability
• Premature Optimization
• Unnecessary complexity
• Debugging

Solutions

1. Remove all compiler directives.
2. If you want different behavior, model it with objects
3. If you think there’s a performance penalty, make a serious benchmark instead of doing premature optimization.

Sample Code

Wrong

Right

Detection

This is a syntactic directive promoted by several languages, therefore it is easy to detect and replace with real behavior.

Tags

• Compilers
• Metaprogramming

Conclusion

Adding an extra layer of complexity makes debugging very difficult. This technique was used when memory and CPU were scarce. …