Dumb Data Class
This articles describes what’s bad about dumb data holding classes. It describes how to refactor Data Classes. Also Code Smells are introduced briefly, of which Data Class is one.
My daily posts still take too long to write, so I choose an even simpler topic for today: Data Classes.
What are Code Smells?
Code Smells are indications, that something may be wrong with your code. They are no hard proofs to point at. Instead they give you hints and serve as examples how to do it not.
Code Smells apply to object-oriented code only. One of these Code Smells is called Data Class.
What are Data Classes?
Data Classes are classes, which only contain fields, getters and setters. Or even worse: only public fields. They are just dumb data holders.
;getFieldB();setFieldA();setFieldB()%5D.png)
A Data Class has no functionality, only data.
Are they really so bad?
When you do some quick prototyping and need to store and transfer data without too much coding effort, they are sometimes a good compromise.
But when your project grows, you should fix this to accomplish one major goal of object orientation: Low Coupling between classes. You want as few dependencies between your classes as possible. But currently everything that’s done with your data, is done in other classes:
Everyone but the Data Class ifself uses its data. This results in high coupling.
What to do about it?
To achieve a low coupling and a high cohesion you need to put the methods in the classes they’re working on most. If you already introduced a Data Class you either need to move the methods closer to the fields or vice versa:
Moving the methods into the Data Class itself eliminates the dependencies.
This eliminates the dependencies and thus lowers the coupling between the classes.
If no more class accesses the fields, you can even remove their getters and setters and leave them private:
;useFieldB();useFieldsAB()%5D.png)
If not required anymore, the public accessors to the fields can be removed.
Now our DataClass no longer smells like a Data Class. We reduced the coupling and from this point we could change the ex-DataClass without effecting the other classes. Enjoy your great code 🙂
Cheers,
Waog
Waog 
Too hard to understand? Should I have better taken concrete examples like “Car”, “Engine”, etc. instead of “Class A”, “Class B”, etc.?
LikeLike
Pingback: Code Smell: Feature Envy | Waog
Pingback: Beyond coding – Levels of Errors in Software Development – Part 1 | Waog
hey waog, nice post but i can not follow all of your thoughts. why does the refactoring delete the coupling? because if method foo of class A still need to use method useFieldA(), then there is still a coupling to the DataClass (same game with the other two classes).
LikeLike
ok am i right with the thought that method useFieldA() may couples more than one time to the class and the switch of this method results in a coupling of 1 ?
LikeLike
Hey Matze, thx for reading and commenting 🙂
The problem here is the vague meaning of “coupling”. You are looking at the coupling between the method and the field, and observed correctly that this coupling doesn’t change. While I described the coupling between the classes.
Before the refactoring “Class A” is coupled to “DataClass”, because it uses fields of DataClass. After the Refactoring “Class A” is decoupled from “DataClass”, because it’s not dependent on this class anymore.
In Objectoriented design, you normally try to reduce the coupling *between* classes, not *inside* classes.
LikeLike
Hey Waog,
Great post, very clear and well explained.
LikeLiked by 1 person
Pingback: Java + Project Lombok = sincere try at solving wrong problem – Java magic blog
Thanks for linking my Code Smell Blog Post 🙂
LikeLike
Pingback: Java class: The Good, The Bad and The Ugly (part 2) – Java magic blog