Ответ 1
Я обычно добавляю 'DTO' в конец имени класса, а также помещаю все DTO в свой собственный пакет. В вашем примере я бы назвал его com.x.core.dto.CarDTO.
Учитывая этот сценарий, когда у вас есть "объекты переноса" (POJO только с помощью геттеров/сеттеров), которые передаются клиентской библиотекой в ваш API, как лучше всего назвать объекты переноса?
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();
}
}
В этом примере ваш основной класс и ваш объект передачи имеют имя Car
. Они находятся в разных пакетах, но я думаю, что это смущает одно имя. Существует ли наилучшая практика о том, как назвать объекты переноса?
Я обычно добавляю 'DTO' в конец имени класса, а также помещаю все DTO в свой собственный пакет. В вашем примере я бы назвал его com.x.core.dto.CarDTO.
D ata T перевод O bject классы должны соответствовать соглашению об именах, определенному в спецификации языка Java:
Имена типов классов должны быть описательными существительными или именными фразами, не слишком длинными, в смешанном регистре, причем первая буква каждого слова пишется с большой буквы.
ClassLoader SecurityManager Thread Dictionary BufferedInputStream
[...]
Суффикс имени класса с помощью DTO или Dto не имеет особого смысла и мало что говорит о самом классе. Попробуйте использовать имена, которые описывают цель ваших занятий.
Вот неполный список предложений имен, которые вы можете использовать:
Note 1: Whether acronyms or all capitalized words should be handled as words or not, I guess it up to you. Check the Java API and you will find some stumbles like [TG41] / [TG42]. Both classes are in the same package and the name convention is not consistent. [TG43] does not 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 a cached copy from Web Archive).
Добавление DTO или DAO или что-либо еще нарушает DRY. FQN прекрасно, особенно если они действительно то же самое.
Я не думаю, что для класса, демонстрирующего такое поведение, есть лучшая практика или конвенция. Мне лично не нравится слово Object в любом из имен классов. Вы можете либо использовать некоторую квалификацию, как Poko.Car, либо использовать какое-либо соглашение об именах, например Автомобиль (для POJO) CarDa (для доступа к данным) CarBiz (для класса бизнес-домена)
Или если вы не возражаете против объекта word в имени класса, переходите к чему-то вроде CarDto (объект передачи данных автомобиля)
Используйте соглашение, подходящее для других кодовых условных условных обозначений. Я лично использую суффикс "TO" (например, объект передачи данных, связанный с классом домена Customer, называется CustomerTO). Также структура пакета должна передать намерение каждого типа класса (so.foo.domain.Customer и so.foo.transport.CustomerTO)