Skip to main content
HashnodeMaximiliano Contieri - Software DesignMaximiliano Contieri - Software Design

Command Palette

Search for a command to run...

Code Smell 40 - DTOs

Updated
•2 min read
Code Smell 40 - DTOs
M
Maxi Contieri

I’m a senior software engineer loving clean code, and declarative designs. S.O.L.I.D. and agile methodologies fan.

Part of seriesCode Smells

Data Transfer Objects (DTOs) are widely used, and they 'solve' real problems, do they?

Problems

  • Anemic Object

  • Inconsistent Data

  • Duplicated logic

  • Duplicated structure

  • Class Polluting

  • Information Hiding Violation

  • Code repeated among mutators, accessors, serializers, parsers

  • Ripple Effect

  • Data integrity

Solutions

  1. Transfer anemic data on arrays.

  2. Use real business objects.

  3. If we want to transfer partial objects: use proxies or null objects to break the reference graph.

Sample Code

Wrong

https://gist.github.com/mcsee/91a2d630101ba6137f64195e76c1b266
https://gist.github.com/mcsee/e1ecfdec6bd0fbe72f2d9ee7664af1c4

Detection

We can use the same anemic object detectors.

We can check for anemic classes with no business object behavior (removing serializes, constructors, mutators etc).

Tags

  • Anemic

Conclusion

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.

Relations

https://maximilianocontieri.com/code-smell-01-anemic-models

https://maximilianocontieri.com/code-smell-13-empty-constructors
https://mcsee.hashnode.dev/code-smell-20-premature-optimization
https://maximilianocontieri.com/code-smell-28-setters

More info

https://martinfowler.com/bliki/LocalDTO.html
https://refactoring.guru/es/smells/data-class
https://softwareengineering.stackexchange.com/questions/171457/what-is-the-point-of-using-dto-data-transfer-objects

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.

Martin Fowler

https://mcsee.hashnode.dev/software-engineering-great-quotes

This article is part of the CodeSmell Series.

https://mcsee.hashnode.dev/how-to-find-the-stinky-parts-of-your-code
#programming#code-smell-1#2articles1week#clean-code
2.7K views

Comments (1)

Join the discussion
A
Alexandre Roba5y ago

Hi Maxi, thanks for sharing your though on the subject. I have to say, I do not agree with your analysis on the DTOs for the following reason: 1) In the list of Problems you mention the following

  • Anemic object: Well DTOs are object in the sense they are instance of a class BUT their purpose is not to provide any other feature than transporting information. NOT logic. As such their roles is to serve as projection of data. They are containers. This would be like saying a Tuple is anemic....
  • Inconsistent data: From what angle? They are not suppose to be the source of any data. they are suppose to be used to transport data.
  • Duplicated Logic: They cannot have any logic. They are object but they should be immutable. They are simply a tool to model parameters in an API. They should not be confused to Value Object...
  • Duplicated Structure: Again they are there to serve as container with predefined structure. They no not represent "Entities" or "Value Object". They are used to transfer data between one system, world, model.. to another...
  • Class poluting: I do not understand that point. You will probably model them using a class. Do you mean poluting the entities of your model? Then again they should not be part of your model as such... They are part of the contract or the api your model expose. as a mean to structure the API of your model for example...)

I will not comment on every point of your assumptions as I believe their were listed based on an wrong use of the DTOs.

My point is DTOs are predifined tuples. No logic. Just a tool to define a projection of your famous "object". If you start adding logic on them then I guess you are building something closer to a Value object or ADTs in FP. When building API (Not limited to inter system api but also apis for other "objects" they are pretty handy to structure this API.

thanks again for sharing your view.

Alex.

M
Maxi Contieri5y ago

Hi Alexandre Roba, thank you very much for your comments. We agree they are as anemic as tuples or structs. So, why should they exist in an OOP world?

They are handy if we get used to duplicating object and treat them as data. I don't like any of them.

Most of the smells are related to handy solutions that generates duplication and coupling.

Since many languages favor this kind of solutions, and we are eager to change languages we are fine with this state-of-the-art.

My point with many code smells is: we deserve to build better tools. Less handy but more engineering ones.

If you learned something new from Employee domain you should change just a single point (probably employee class). This is DRY principle. Changing Employee class, EmployeeDTO, EmployeeDAO etc, is error prone. If you need to transfer and Employee, just transfer and Employee. Not an anemic duplicated tuple.

A
Alexandre Roba5y ago

Hi Maxi Contieri, indeed, I guess your point make sense in this particular programming paradigm. I can understand your point when talking about Employee class, EmployeeDTO, EmployeeDAO and in a classic OO multi tier application. Functional Programming have a different usage of DTOs and serve at the foundation of their Algebraic Data Types. They are no code smell at all in this context :p

M
Maxi Contieri5y ago

Alexandre Roba I love F.P. purity.

I wish we had their immutability, no side effects, high order functions and many more of its elegance.

But I don't have actual experience on FP, so I cannot talk about DTOs on an FP context.

My articles are related to OOP where I have some experience and cannot discuss other paradigms.

Code Smells

Part 1 of 50

In this series, we will see several symptoms and situations that make us doubt the quality of our developments. We will present possible solutions. Most are just clues. They are no hard rules.

More from this blog

M

Maximiliano Contieri - Software Design

474 posts

Learn something new every day. 💻 CS software engineer 👷working 👨🏽‍🏫teaching ✍🏾writing 🎨Software design 🏢SOLID 🌉TDD 👴Legacy

Write me at info(at)maximilianocontieri.com