Структурирование возвращаемых результатов

Question

Я ищу способ, которым я могу структурировать перечисления java эффективным / элегантным способом. Эти перечисления содержат возвращаемые результаты.

• есть такие функции, как «удалить элемент» (перечисления: OK, DOESNT_EXIST, ACCESS_DENIED ..) или создать элемент (OK, ALREADY_EXISTS, ACCESS_DENIED ..), changeItem (OK) , INVALID_PARAMETER, INVALID_CLASS, ACCESS_DENIED)
• Как вы видите, они имеют как собственные, так и общие перечисления. поэтому некоторые перечисления должны быть реализованы в каждой возвращаемой функции (OK, ACCESS_DENIED), в то время как другие являются исключительными (DOESNT_EXIST, ALREADY_EXISTS ...).
• также, существуют сложные функции, такие как changeOrCreate, где элемент может быть создан, если он не существует и не изменяется в противном случае (перечисления: все перечисления createItem, все перечисления changeItem).

В принципе я могу

1. создавать различные перечисления для каждой функции (createItemResult, changeItemResult ..) или
2. поместите их всех в один класс перечисления RESULT.

Но что бы я ни выбрал, я никогда не смогу выполнить sh все эти

• Когда происходит сбой такой сложной функции, как «changeOrCreate», я хочу знать, было ли возвращенное перечисление «ACCESS_DENIED» вызвано созданием или изменением.
• Я бы предпочел, чтобы вызывающая сторона любой функции получала такой же enumType
• (я бы предпочел, чтобы функции no могли возвращать недопустимые перечисления. Например: createUser не должен иметь DOESNT_EXIST)

Есть идеи? Или существует какое-либо соглашение для перечислений возвращаемого типа?

Обновление: причина, по которой я не могу использовать исключения (нестандартные), заключается в том, что я должен предоставить API, и требовалось, чтобы исключения не создавались.

Answer 1

Когда происходит сбой сложной функции, такой как "changeOrCreate", я хочу знать, было ли возвращенное перечисление "ACCESS_DENIED" вызвано созданием или изменением.

Затем назовите их CREATE_DENIED и CHANGE_DENIED, или что-то в этом роде.

Я бы предпочел, чтобы вызывающая сторона любой функции получала тот же enumType

Так что один класс перечисления RESULT вы

Я бы предпочел, чтобы функции no могли возвращать недопустимые перечисления.

Поскольку вы пишете функции, вы контролируете, какое из перечислений оно возвращает , т.е. вы убедитесь, что createUser никогда не вернется DOESNT_EXIST.

Answer 2

Кажется, вы используете HTTP-коды состояния в Java, и хотя это может хорошо работать для вашей программы, это не элегантный способ написания Java программ.

Java имеет исключения по двум причинам (о которых я знаю):

• Произошло что-то неожиданное, и программа не знает, как с этим справиться. Что вы делаете: бросьте его на следующий слой ~!
• Что-то ожидаемое произошло, так что вы ловите это и решаете его.

Поскольку вы ожидаете исключения, что это значит для вас это:

Создайте несколько классов для ваших перечислений, например UserNotAuthorizedException (или просто используйте встроенную AuthenticationException), и добавьте их в свою программу.

Если вы хотите Зная, кто не получил доступ, вы можете выбрать его с аргументом для вашего исключения (идентификатор для каждого варианта использования, экземпляр, который не удалось (который может включать тип stati c)), или даже строку. вам), вы можете создать подкласс ...

В конце концов, Java любит занятия.