сценарий использования / бизнес-логика, возвращающие несколько значений передовой опыт?

Question

Я реализую чистую архитектуру в приложении. У меня есть слой, где классы application / usecase выполняют бизнес-логику и взаимодействуют с множеством исходящих портов (интерфейсы для адаптеров для вызовов базы данных, вызовов http api и т. Д.). Вариант использования возвращает значение / модель веб-контроллеру (который отображает выходные данные для пользователя приложения).

Из-за сложности бизнес-логики существует много печальных путей и счастливых путей (которыеразличные типы объектов с различным состоянием), а также исключения, которые могут всплывать на веб-контроллере. Исключения обрабатываются обработчиком ошибок с общим ответом http и регистрируются.

Чтобы вернуть счастливые и грустные пути, я обернул их в объект из двух полей. Но я чувствую, что это запах кода, поскольку у меня всегда будет одно поле, возвращающее ноль. Таким образом, в веб-контроллере / сервлете есть проверки в заполненном поле, чтобы определить правильный HTTP-ответ. Является ли это хорошим способом сделать это?

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

Я видел другие способы возврата нескольких значений, например

• использование кортежа
• Возвращение одного объекта, но каждое поле является списком, что устраняет необходимость в нулевом значении в качестве пустого поля, и использование пустого списка
• Использование карты

Существуют ли другие способы возврата нескольких значений без использования пустых полей или использования исключений (как описано выше)?

Answer 1

Существуют ли другие способы возврата нескольких значений без использования пустых полей или использования исключений (как описано выше)?

В Java (и POO языки) обычным способом сделать это является наследование.

Возможно, раньше или позже вы попадете в проблему Expression , то есть , которую вы должныбудьте осторожны, когда включить процесс в иерархию классов, а когда определять этот процесс изолированно .

Если ваш процесс имеет смысл в иерархии, определите его в нем:

abstract class Response {
    abstract boolean isSuccess();
    abstract String getMessage();
}

class ErrorResponse extends Response {
    boolean isSucess() { return false; }
    String getMessage() { return "Something went wrong."; }
}

class SuccessResponse extends Response {
    boolean isSucess() { return true; }
    String getMessage() { return "Everything went well."; }
}

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

Color getResponseColor(Response rs) {
    if(rs instanceof NetworkErrorResponse || rs instanceof ServerErrorResponse) {
        return Colors.WITHOUT_SERVICE_COLOR;
    }
    return rs.isSuccess() ? Colors.SUCCESS_COLOR: Colors.ERROR_COLOR;
}

Как видите, включение принятия цветовых решений в иерархию классов не имеет большого смысла.

Наконец, поскольку вы собираетесь сериализовать свои сообщения, вы должны убедиться, что транспортный протокол поддерживает наследование.