85

Given this scenario where you have "transfer objects" (POJO's with just getters/setters) which are passed by a client library to your API, what is the best way to name the transfer objects?

package com.x.core; 

public class Car {
        private String make;
        private String model;

        public Car(com.x.clientapi.Car car) {
             this.make = car.getMake();
             this.model = car.getModel();
        }
}

In this example your main class and your transfer object both have the name Car. They are in different packages but I think it's confusing to have the same name. Is there a best practice on how to name the transfer objects?

Marcus Leon
  • 55,199
  • 118
  • 297
  • 429

7 Answers7

253

Data Transfer Object classes should follow the name convention defined in the Java Language Specification:

Names of class types should be descriptive nouns or noun phrases, not overly long, in mixed case with the first letter of each word capitalized.

ClassLoader
SecurityManager
Thread
Dictionary
BufferedInputStream

[...]

Suffixing a class name with DTO or Dto won't tell much about the class itself besides indicating it carries data without any behaviour. So, instead of just calling your objects DTO, it might be worth considering more meaningful names, which convey better semantics for the classes.

Here is a non-exhaustive list of name suggestions you could use:

  • SomeSortOfCommand
  • SomeSortOfConfiguration
  • SomeSortOfCredentials
  • SomeSortOfDetails
  • SomeSortOfElement
  • SomeSortOfEvent
  • SomeSortOfFilter
  • SomeSortOfHeader
  • SomeSortOfInput
  • SomeSortOfInstruction
  • SomeSortOfItem
  • SomeSortOfMessage
  • SomeSortOfMetadata
  • SomeSortOfOperation
  • SomeSortOfOutput
  • SomeSortOfPayload
  • SomeSortOfProjection
  • SomeSortOfProperties
  • SomeSortOfQueryParameter
  • SomeSortOfQueryResult
  • SomeSortOfRepresentation
  • SomeSortOfRequest
  • SomeSortOfResource
  • SomeSortOfResponse
  • SomeSortOfResult
  • SomeSortOfRow
  • SomeSortOfSettings
  • SomeSortOfSpecification
  • SomeSortOfStatus
  • SomeSortOfSummary

Note 1: Whether acronyms or all capitalized words should be handled as words or not, I guess it's up to you. Check the Java API and you will find some stumbles like ZipInputStream / GZIPInputStream. Both classes are in the same package and the name convention is not consistent. HttpURLConnection doesn't show any consistency with acronyms either.

Note 2: Some names listed above were borrowed from this article written by Richard Dingwall (the original article seems to be no longer available, so here's a cached copy from Web Archive).

cassiomolin
  • 124,154
  • 35
  • 280
  • 359
  • 6
    Not really convinced. It is common for exception classes to have "Exception" suffix for instance. Do you think this is bad practice too. Can you please formulize in what cases it is accepteble to have static suffix. Thank you! – Oleksandr Papchenko Aug 30 '18 at 11:15
  • 6
    @OleksandrPapchenko I'm not sure if it's a fair comparison. The `DTO` suffix is broad, abstract and doesn't tell much about the class itself. If you intend to use the DTO pattern, pick a name that describes what the class _is meant for_. For example, `QueryParameter` and `QueryResult` suffixes are the way more clear than the `DTO` suffix to define a class that represents a query parameter or the result of a query. – cassiomolin Sep 03 '18 at 08:15
  • 43
    "is not really meaningful and doesn't tell much about the class itself" It describes exactly what the purpose of the class is, data transfer. A Car class is a real-world entity, it is expected to contain behaviour and business constraints. A CarDto class is a class that contains data for transfer. Especially when the term DTO is widely known, someone who sees CarDto will know exactly what it is, as opposed to seeing two Car classes. – Orestis P. Dec 31 '18 at 17:19
  • 1
    Seem like the post is still there, just under another domain: https://richarddingwall.name/2010/04/17/try-not-to-call-your-objects-dtos/ – DDMC Apr 07 '21 at 14:09
61

I generally add 'DTO' to the end of the Class name as well as place all the DTO's in their own package. In your example I would call it com.x.core.dto.CarDTO.

IaCoder
  • 12,300
  • 11
  • 37
  • 45
  • 3
    It isn't particularly pretty but it does mean that you can import both the dto and the "main" class. Not having the suffix makes copy code really ugly with all the extra package names. – Michael Rutherfurd Nov 13 '09 at 04:55
  • 9
    What about situation when I have multiple DTOs of the same class? – Flying Dumpling Dec 31 '13 at 12:23
  • 48
    I would avoid capitals in DTO - If an abbreviation is used in a class name, it makes it a bit less readable. That's why I prefer `CarDto`. – Vlasec Mar 30 '15 at 08:20
  • 2
    When you write "Dto", you're still writing an abbreviation. So, what difference does it make to use lowercase for "t" and "o"? Is it because when you use lowercase, the word after "Dto" is identified easier? – SametSahin Feb 25 '22 at 00:38
  • 1
    @SametSahin I think it is better to write it lowercase so that you respect JavaCamelCasing naming conventions . And it looks more readable, although that is up to personal preferences. – Dorian Naaji Jun 19 '23 at 12:10
8

Adding DTO or DAO or anything else violates DRY. The FQN is perfectly fine, especially if they're really the same thing.

Jim Barrows
  • 3,634
  • 1
  • 25
  • 36
  • 2
    I don't disagree.. except I find the code confusing to read with the same name. You can specify the FQN where the client API is used but that is also somewhat cumbersome. – Marcus Leon Nov 12 '09 at 19:57
  • I find typing DTO/DAO and any other suffix to be FAR FAR more cumbersome, even with autocomplete. – Jim Barrows Nov 15 '09 at 16:50
  • 23
    Clarity is also an important consideration. DRY is important but not inviolable. Most principles we follow can be violated when other considerations turn out to be just as or more important. Being pedantic about DRY can lead to bad smells in code also. – Matt Friedman Dec 06 '13 at 16:58
  • 24
    Adding nothing makes it a lot harder to find the correct object in IDE when you have original entity, DTO object, cache object, NoSQL object, all named the same, just in a different package. – Vlasec Mar 30 '15 at 08:21
  • 2
    The FQN is and should't be used in the code. Sheesh. – magallanes Jul 13 '17 at 14:08
  • 13
    FQN means Fully Qualified Name, just in case someone was wondering – kiedysktos Sep 11 '20 at 13:37
  • Adding three letters like DTO, to the class name makes code much more readable comparing to using FQN. It's quite common to add suffixes like `Map`, `List`, `Query`, `Table`, `Service`, etc. to make the purpose of the class clear, and that's perfectly fine. We are engineers, we know what DTO is. But we need more time to understand what's the purpose of "Car" class(is it a table? is it a DTO?) comparing to the CarDto, which is clear by the first glance. – dgebert Oct 17 '22 at 10:37
2

I read the answers above, I just want to add something. I somehow hate the word DTO, It seems like it is screaming at me. So I try to use Payload suffix. For example, CarPayload.

ata
  • 1,254
  • 1
  • 9
  • 30
  • 3
    Its always better to use some common names. Because it makes other people to understand your code faster and better. – Alex Feb 18 '22 at 15:30
  • @Alex look at the word itself, `DTO` how can you understand something from that? Just an abbreviation. – ata Feb 20 '22 at 13:01
  • 1
    the word make it different from just models/entities – Alex Mar 17 '22 at 09:59
  • @ata because it's a design pattern and when people see "DTO" they'll know what you're talking about. But if Payload works for you, use it – koraljko Mar 14 '23 at 08:53
1

I dont think there is a best practice or convention for a class exhibiting this kind of behavior. I personally dont like the word Object in any of the class names. You could either use some qualification like Poko.Car or use some naming convention like Car (for POJO) CarDa (for data access) CarBiz ( for business domain class)

Or if you dont mind the word object in a class name go for something like CarDto (Car Data Transfer Object)

Perpetualcoder
  • 13,501
  • 9
  • 64
  • 99
0

Use a convention that is suitable among the other code conventions you are using. I personally use the suffix "TO" (e.g. the data transfer object associated to the Customer domain class is named CustomerTO). Also the package structure should convey the intent of each type of class (so.foo.domain.Customer and so.foo.transport.CustomerTO)

JuanZe
  • 8,007
  • 44
  • 58
0

abbreviation/acronyms should be CamelCase

since DTO is a valid abbreviation/acronym (there are tons of valid abbreviation/acronyms, eg: CPU, JSON, REST, HTTP) we treat is as any other word: CamelCase

an abbreviation/acronym is valid (see java naming conventions) when the abbreviation/acronym itself is commonly known and widely understood, short: when there is no mistake what this abbreviation/acronym could mean.

Car car = new Car();
CarDto carDto = new CarMapper().toDto(car);

side note - things evolve:

using camel case for abbrevation was not always implemented, there is a lot of old code that does not apply this Rule (yet), see URL (since JDK1.0) URL. Some code has evolved and is a mix of both HttpURLConnection (since JDK1.1) HTTP, URL. Newer code mostly follows the Code convetion on abbrevation, see for example code from the spring framework RestTemplate REST.

Martin Frank
  • 3,445
  • 1
  • 27
  • 47