Why the first instruction we learn to program should be the last to use.

Image for post
Image for post

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.

Image for post
Image for post
Photo by Przemysław Bromberek in Pixabay

The Problem

Most IF sentences are coupled to accidental decisions. …


Incomplete objects cause lots of issues.

Image for post
Image for post
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

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

This article is part of the CodeSmell Series.


The code smells bad. Let’s see how to change the aromas.

Image for post
Image for post

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

… and many more to come.

Image for post
Image for post

Smells are certain structures in the code that suggest (sometimes they scream for) the possibility of refactoring.

Martin Fowler

Part of the objective of this series of articles is to generate spaces for debate and discussion on software design.

We look forward to comments and suggestions on this article.


Your objects are a bunch of public attributes without behavior.

Image for post
Image for post
Photo by Stacey Vandergriff on Unsplash

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 article is part of the CodeSmell Series.


When an object changes its state the best solution is to change the attribute, isn’t it?

Image for post
Image for post
Photo by Tom Crew on Unsplash

Problems

  • Mutability
  • Attributes polluting
  • Setters

Solutions

1 — Model states as mathematical set inclusion.

2 — State is accidental, take it away from the object.

Examples

  • State diagrams

Sample Code

Wrong

Right

Detection

If we want to be extreme, we should consider every setter to be a potential state change. Linters can warn us. But we might end up getting too many false positives.

Exceptions

  • Over Design
  • Performance issues (if a serious benchmark supports it).

Tags

  • Mutation

Conclusion

This technique is very elegant but can lead to over design. For example changing a visual component its color should be a counterexample to this smell.

We should be aware and very caution like with any other smell.

They are hints and not rigid rules.

Relations

More info

First make the change easy (warning: this might be hard), then make the easy change.

Kent Beck

This article is part of the CodeSmell Series.


We all love T.D.D. We know its benefits, we have read a thousand tutorials on how to build a system using this technique. But this not feasible for currently legacy systems

Image for post
Image for post
Photo by Anne Nygård on Unsplash

What is TDD?

Test-driven development (TDD) is a software DEVELOPMENT process that relies on the repetition of a very short development cycle.

We turn requirements into very specific test cases.

We improve software so all tests pass.

This is opposed to incorporating functionality that has not been proven to comply with requirements.

Created in 2003 by Kent Beck (also the xUnit testing Framework testing system author).

The Cycle

1) Add a test (it must fail)

Solely based on behavior. Forgetting everything about accidental implementation.

2) Run all tests. The new test must fail. All the rest should pass.

3) Write the simplest possible solution to make the test pass. The programmer must not write code that is beyond the functionality the test checks. (K.I.S.S. and Y.A.G.N.I


A class defines objects with lots of attributes.

Image for post
Image for post
Photo by Andy Li on Unsplash

Problems

  • Low Cohesion
  • Coupling
  • Maintainability
  • Readability

Solutions

  1. Find methods related to attributes.
  2. Cluster these methods.
  3. Break the object related to those clusters.
  4. Find real objects related to this new objects and replace existing references.

Examples

  • DTOs
  • Denormalized table rows

Sample Code

Wrong

Right

Detection

Most linters warn when you declare too many attributes. Setting a good warning threshold should be easy.

Tags

  • primitive

Conclusion

Bloated objects know too much and are very difficult to change due to cohesion.

Developers change these objects a lot, so they bring merge conflicts and are a common problems source.

Relations

So much complexity in software comes from trying to make one thing do two things.

Ryan Singer

This article is part of the CodeSmell Series.


Abbreviating is very important so that we look smart and save memory and mind space

Image for post
Image for post
Photo by Jessica Knowlden on Unsplash

Problems

  • Coupling
  • Bad Naming
  • Declarativeness
  • Ambiguity
  • Readability
  • Premature Optimization

Solutions

  1. Use meaningful and declararive names.

Examples

  • Variable naming
  • Function naming
  • Package naming
  • Class Naming

Sample Code

Wrong

Right

Detection

We can’t automate choosing what is a short name and a declarative.

Some “modern” and shinny languages enforce this bad practice. So we should wisely choose a good language instead.

Tags

  • Declarative

Conclusion

Computer science was born from the mother of science (mathematics). In math, the assignment of single letter variables (i, j, x, y) is a good practice.

The concept of reference arose from the variable.

Many people wondered why mathematicians can work with such short variables, and computer scientists cannot. …


The most used and (in)famous design pattern in the world is causing us great harm.

Image for post
Image for post
Photo by Maria Teneva on Unsplash

Problems

  • Coupling
  • Testability
  • Accidental implementation problems.
  • Multi threading issues.
  • Static methods polluting.
  • Object creation contract violation.
  • Bijection mismatch.
  • Memory issues.
  • Premature Optimization.

Solutions

  1. Avoid it.
  2. Use contextual unique objects.
  3. Benchmark object creation.

Examples

  • Database Access
  • Globals
  • Loggers
  • Helpers

Sample Code

Wrong

God is the archetypical singleton example.

Right

Detection

This is a design pattern. We should avoid it by policy.

We can add linter rules for patterns like ‘getInstance()’ so new developers cannot infect code with this anti-pattern.

Tags

  • Globals

Conclusion

This is an historical mistake already acknowledged by the community. Nevertheless, lazy developers bring it again and again. We need to reach a consensus on its drawbacks.

Relations

More info

The Diagram is Not the Model. The model is not the diagram. It is an abstraction, a set of concepts and relationships between them.

Eric Evans

This article is part of the CodeSmell Series.


Adding persistence, serialization, displaying, importing, exporting code to an object bloats its protocol and brings coupling.

Image for post
Image for post
Photo by Robert Bye on Unsplash

Problems

  • Readability
  • Coupling
  • Maintainability

Solutions

  1. Keep your objects clean.
  2. Decouple business objects.
  3. Separate accidental concerns: Move Persistence, Formatting, Serialization to special objects.
  4. Keep essential protocol using bijection.

Examples

  • Persistence
  • Identifiers
  • Serialization
  • Formatting

Sample Code

Wrong

Right

Detection

It is difficult (but not impossible) to create linting rules based on naming and hinting for suspect names.

Exceptions

  • Some frameworks force us to inject dirty code in our objects. (For example identifiers).

We should try to use better languages/frameworks.

Tags

  • Declarative

Conclusion

We are very used to see business objects polluted. This is normal. We need to reflect on the consequences and coupling from these designs.

Simple things should be simple, complex things should be possible.

Alan Kay

This article is part of the CodeSmell Series.

About

Maximiliano Contieri

I’m senior software engineer specialized in declarative designs. S.O.L.I.D. and agile methodologies fan.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store