Code Smell 40 — DTOs
DTOs are widely used, and they ‘solve’ real problems, do they?
- Anemic Object
- Inconsistent Data
- Duplicated logic
- Duplicated structure
- Class Polluting
- Information Hiding Violation
- Code repeated among mutators, accessors, serializers, parsers
- Ripple Effect
- Data integrity
- Transfer anemic data on arrays.
- Use real business objects.
- If we want to transfer partial objects: use proxies or null objects to break the reference graph.
We can use the same anemic object detectors.
We can check for anemic classes with no business object behavior (removing serializes, constructors, mutators etc).
DTOs are a tool and an established practice in some languages. We should use them with care and responsibility.
If we need to disassemble our objects in order to send them away from our realms, we need to be extremely cautioned. Since dismembered objects have no integrity considerations.
His author warns us about its actual abuse.
Code Smell 01 — Anemic Models
Your objects are a bunch of public attributes without behavior.
Code Smell 20 — Premature Optimization
Planning ahead of time needs a crystal ball no developer has.
Code Smell 28 — Setters
The first exercise junior programmers do. IDEs, tutorial and senior developers keep teaching them this anti-pattern.
If you've been keeping an eye on my fellow ThoughtBloggers you'll know that it seems one of my fowlbots has blown a…
A data class refers to a class that contains only fields and crude methods for accessing them (getters and setters)…
The best smells are something that’s easy to spot and most of time lead you to really interesting problems. Data classes (classes with all data and no behavior) are good examples of this. You look at them and ask yourself what behavior should be in this class.
This article is part of the CodeSmell Series.