Serie : Choosing Names – 1. part : DTOs

This article is the beginning of a small series about choosing names for classes (like DTOs, entities, enums …).
Every part of this serie is focused on a different type of class, the actual article, for example, deals with possible pattern, pre- and postfixing of names for DTOs.

Background

for this series is a discussion that came up during our last bigger refactoring:
The discussion begun with the simple question :  “How should we name this kind of classes?”. The goal of this question where classes, which intention is to transfer data between instances; the classic Data Transfer Object (DTO).
The first decision about structuring (at packet level) and how the names should look like, were very quick done. All classes of this kind, except of database entities for JPA, should be stored in the package dto of the according parent package of the business logic. Additionally all this kind of classes must be suffixed with DTO.
While we did the refactoring – pair programming rules – we asked ourselfs : “Does that really make sense?”
And this is the point where the series starts: With the

DTO

Definition

is a design pattern used to transfer data between software application subsystems. DTOs are often used in conjunction with data access objects to retrieve data from a database. (Wikipedia)

This means, that a DTO is a class that defines which data – for an explicit case – can be transfered between different components of a system.
Fine. But one question is left: What’s a meaningful name for a class like this?
Let’s have a look on the environment where the DTO lives. It has no logic and is created, used and consumed by classes like beans, controller, managers, etc.;classes with a small portion of logic.
For the latter kind of classes we have more or less meaningful name patterns
  • EJB have the suffix Bean,
  • Classes that act as a controller, are usually suffixed with Controller and
  • manager classes, like a ConnectionPoolManager, uses Manager as suffix.
But, is their a reason against DTO as suffix for DTOs?
Yes, in my opinion.
From my point of view is difference between this “logic” classes and a DTO that, we can express with Bean, Controller, Manager … what the purpose of the class is. But a class suffixed with DTO will hide this initial purpose.
Let’s have a look on some examples:
  • CustomerAdministrationService
  • ConnectionPoolManager
  • CustomerManagementBean
  • SkyColorFactory
  • SkyColor
  • Mail
  • CustomerStatusResponseDTO
  • HealthStatusDTO
  • SubscriberModelDTO
  • ScreenResolutionDTO
The upper groups purpose is, due to the names, precisely expressed.
The purpose of the lower group is, on the other hand, much harder to understand. It’s clear, that this classes will transport some data, but to discover what kind of data for which purpose is much more difficult. We need to read backwards to capture things before this omnipresent DTO suffix. This means additional effort and the potential to misuse / misunderstand the class.
Let’s kick the suffix and see what will happen:
  • CustomerStatusResponse
  • HealthStatus
  • SubscriberModel
  • ScreenResolution
Cool, much better. Now it’s clear and easily captured what kind of data this classes will transport and, much more important, we have an idea what’s the direction of the data flow is and where this classes will be used.

Conclusion

The usage of DTO as postfix / prefix for a Data Transfer Object should be avoided, because
  • it’s much harder to catch where this object will be created, used or consumed
  • it’s much harder to understand what kind of data will be transfered
  • it can create new and unnecessary questions 
In my opinion, meaningful names, should be preferred. Like
  • Model for moddeling classes
  • Response for objects that transfers an answer / response
  • Request for objects that transfers data for a request
  • Status for status objects
 
20 Kudos
Don't
move!

Leave a Reply

Your email address will not be published. Required fields are marked *