@galliard

Как избежать глаголов в наименовании классов?

Я всегда считал, и до сих пор считаю, что класс описывает некоторую сущность, поэтому не может иметь в названии глагол. И вот столкнулся с ситуацией, когда мне "необходимо" именовать класс глаголом. Ну то есть не то чтоб прям так уж необходимо, просто иного решения я придумать так и не смог, поэтому решил написать сюда, вдруг кто что дельное предложит.

Суть вот в чем: есть некий класс DTO-классов, описывающих наборы данных для определенного действия в будущем. Например, CreateUserData, ну то есть набор данных для создания юзера. При этом операций над юзером добрый десяток, и для каждой нужен свой определенный набор данных, поэтому обобщать до UserData я не могу. Ну ок, в случае создания я могу назвать его NewUserData, а если нужно редактирование? Или изменение роли? RoleUserData опять же слишком абстрактно, это может быть создание/изменение/удаление роли, и опять придется добавлять глагол для понятности.

И да, формирование данных и собственно действие над ними находится на разных слоях абстракции, поэтому просто передать нужный набор данных в виде аргументов в метод я не могу, нужен именно класс.
  • Вопрос задан
  • 175 просмотров
Решения вопроса 1
Vapaamies
@Vapaamies
Разработчик будущей ОС для ПК размером 250 МБ
В комбинации CreateUserData — «данные о создании пользователя» — Create — не глагол, а причастие. Английский — язык аналитический, грамматические конструкции выражаются порядком слов. Переводите на русский для проверки, и будет вам счастье.
Ответ написан
Комментировать
Пригласить эксперта
Ответы на вопрос 4
GavriKos
@GavriKos
Конкретно про ваши примеры:
- UserDataCreator
- UserDataEditor

Добавлять глагол можно еще и вот так:
- UserDataRemoveController, UserDataChangeRoleController
Контроллер не лучший пример, но суть понятна, я дума.
Ответ написан
@heahoh
Full stackoverflow developer
Почему бы и нет, если DTO определяется действием, которое будет выполнять какой-нибудь сервис. Думаю спейс конкретного модуля будет достаточно предметно описывать его применение, например:
namespace Exchange\Github\DTO\Request\User\Create;
namespace Exchange\Github\DTO\Request\User\Role\Change;

и т.п. и использовать алиасы, если уже название конретной DTO вызывает смущение
use Exchange\Github\DTO\Request\User\Create as UserCreateDTO;


бтв, если я правильно понял, вы опускаете само словосочитание DTO из класса, поэтому возникает ощущение не объекта, а действия, которое он выполняет, однако DataTransferObject по прежнему участвует в названии класса и само за себя говорит - это класс передачи данных (с какой-то конкретной реализацией)
Ответ написан
vt4a2h
@vt4a2h
Senior software engineer (C++/Qt/boost)
Я вижу несколько подходов:
1) Просто добавлять суффикс Data. На мой взгляд, не слишком описательно и довольно-таки общо.
2) Название данных + операция. Например UserCreate, UserQuery, UserStatus и т.д. Но это не описывает сущность как класс данных.
3) Комбинированный вариант: название + операция + идентификационный суффикс. Что-то вроде UserCreateData. По-моему, это выглядит наиболее приемлемо.
Ответ написан
Комментировать
lxsmkv
@lxsmkv
Test automation engineer
DataForUserCreation или UserCreationDTO
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы