DEV Community

Cover image for Code Smell 35 - State as Properties
Maxi Contieri
Maxi Contieri

Posted on • Updated on • Originally published at

Code Smell 35 - State as Properties

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


  • Mutability

  • Attributes polluting

  • Setters


1 - Model states as mathematical set inclusion.

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


  • State diagrams

Sample Code




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.


  • Over Design

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


  • Mutation


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.


More info



Photo by Tom Crew on Unsplash

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

Kent Beck

Top comments (2)

darkwiiplayer profile image
𒎏Wii 🏳️‍⚧️

I'd go as far as to say getters and setters are always a sign of bad design in OO code. Their only real purpose in that context is as a hack when business constraints don't allow for a more solid (you can also read that as SOLID) design.

Other than that, they're useful when one needs procedural segments in an otherwise OO codebase, mostly to implement some of the lower levels of the logic. Arrays just don't work well with "tell don't ask".

mcsee profile image
Maxi Contieri

I agree

Both setters and getters should be avoided most of the time.

People use them thinking they are protecting their implementation but is exactly the opposite. Next Sunday's code smell is related to that