Как избежать глаголов в наименовании классов? Я всегда считал, и до сих пор считаю, что класс описывает некоторую сущность, поэтому не может иметь в названии глагол. И вот столкнулся с ситуацией, когда мне "необходимо" именовать класс глаголом. Ну то есть не то чтоб прям так уж необходимо, просто иного решения я придумать так и не смог, поэтому решил написать сюда, вдруг кто что дельное предложит.
Суть вот в чем: есть некий класс DTO-классов, описывающих наборы данных для определенного действия в будущем. Например, CreateUserData, ну то есть набор данных для создания юзера. При этом операций над юзером добрый десяток, и для каждой нужен свой определенный набор данных, поэтому обобщать до UserData я не могу. Ну ок, в случае создания я могу назвать его NewUserData, а если нужно редактирование? Или изменение роли? RoleUserData опять же слишком абстрактно, это может быть создание/изменение/удаление роли, и опять придется добавлять глагол для понятности.
И да, формирование данных и собственно действие над ними находится на разных слоях абстракции, поэтому просто передать нужный набор данных в виде аргументов в метод я не могу, нужен именно класс.
Как избежать глаголов в наименовании классов? Я всегда считал, и до сих пор считаю, что класс описывает некоторую сущность, поэтому не может иметь в названии глагол. И вот столкнулся с ситуацией, когда мне "необходимо" именовать класс глаголом. Ну то есть не то чтоб прям так уж необходимо, просто иного решения я придумать так и не смог, поэтому решил написать сюда, вдруг кто что дельное предложит.
Суть вот в чем: есть некий класс DTO-классов, описывающих наборы данных для определенного действия в будущем. Например, CreateUserData, ну то есть набор данных для создания юзера. При этом операций над юзером добрый десяток, и для каждой нужен свой определенный набор данных, поэтому обобщать до UserData я не могу. Ну ок, в случае создания я могу назвать его NewUserData, а если нужно редактирование? Или изменение роли? RoleUserData опять же слишком абстрактно, это может быть создание/изменение/удаление роли, и опять придется добавлять глагол для понятности.
И да, формирование данных и собственно действие над ними находится на разных слоях абстракции, поэтому просто передать нужный набор данных в виде аргументов в метод я не могу, нужен именно класс.
Суть вот в чем: есть некий класс DTO-классов, описывающих наборы данных для определенного действия в будущем. Например, CreateUserData, ну то есть набор данных для создания юзера. При этом операций над юзером добрый десяток, и для каждой нужен свой определенный набор данных, поэтому обобщать до UserData я не могу. Ну ок, в случае создания я могу назвать его NewUserData, а если нужно редактирование? Или изменение роли? RoleUserData опять же слишком абстрактно, это может быть создание/изменение/удаление роли, и опять придется добавлять глагол для понятности.
И да, формирование данных и собственно действие над ними находится на разных слоях абстракции, поэтому просто передать нужный набор данных в виде аргументов в метод я не могу, нужен именно класс.
Не можешь разобраться в этой теме?
Обратись за помощью к экспертам
Гарантированные бесплатные доработки
Быстрое выполнение от 2 часов
Проверка работы на плагиат
Интересные статьи из справочника
Поможем написать учебную работу
Отвечай на вопросы, зарабатывай баллы и трать их на призы.
Подробнее
Подробнее
Для решения данной проблемы можно использовать паттерн именования "сущность + операция". Например, вместо RoleUserData можно назвать класс UserRoleData, где UserRole будет означать конкретную сущность (роль), а Data - данные, необходимые для выполнения определенной операции (получение, изменение, удаление). Таким образом, вы сможете точно указать, для какой конкретной операции предназначен данный класс DTO.
Также можно рассмотреть варианты использования синонимов для глаголов. Например, вместо Create можно использовать Add, New, Insert, а вместо Edit - Modify, Update, Change. Таким образом, вы сможете избежать прямого использования глаголов в названиях классов, сохраняя при этом понятность и ясность их назначения.
В любом случае, важно выбирать такие названия, которые будут ясно отражать суть класса и его функциональность, чтобы другим разработчикам было легче его понять и использовать в дальнейшем.