Code Smell 68 - Getters

Subscribe to my newsletter and never miss my upcoming articles

Listen to this article

Getting things is widespread and safe. But it is a very bad practice.


  • Naming

  • Information Hiding

  • Coupling

  • Encapsulation Violation

  • Mutability

  • Anemic Models


  1. Avoid Getters

  2. Use domain names instead

  3. Protect your implementation decisions.

Sample Code



Getters coincide in certain scenarios with a true responsibility. It will be reasonable for a window to return its color, and it may accidentally store it as color. So a color() method returning the attribute color might be a good solution.

getColor() breaks bijection since it is implementative and has no real counterpart on our mappers.

Most linters can warn us if they detect anemic models with getters and setters.


  • Information Hiding


Getters and Setters are a poorly established practice. Instead of focusing on object behavior (essential), we are desperate to know object guts (accidental) and violate their implementation.


More info


Photo by Vidar Nordli-Mathisen on Unsplash

The value of a prototype is in the education it gives you, not in the code itself.

Alan Cooper

This article is part of the CodeSmell Series.

Mr Rampage's photo

I think you would enjoy this blog post from 2018 about getters-setters as foundational to functional programming. I don't disagree with your point of view, but I think the title may be misleading.

Some interesting patterns such as the getter-getter and setter-setter can be used to achieve laziness in code. The article also shows how getters-setters are foundational for Promises, Observables, and AsyncIterables.

Rodrigo's photo

Interesting article Maxi Contieri. If I get it right (see what I did there ) getters could be fine to be used if we assign a better name by removing the ¨get¨prefix and using a domain name instead. Another restriction is that we should use them only on safe operations, such as reading.

They become a problem when we expose the object internals to mutate its data from the outside, breaking encapsulation as consequence, is that right?