Возвращение сообщений о состоянии

Question

В классах есть методы, такие как "addSomething ()". Это может быть успешным или не успешным. Поэтому статус успеха может отображаться с логическим возвращаемым значением. Но иногда вызов метода может завершиться неудачей по нескольким причинам. «false» отображает это, но только в общем виде. Иногда программист хочет узнать причину, почему что-то не получилось. Полезно ли для этой цели предоставлять собственный класс отчета, который предлагает такую ​​функциональность?

public class Report {
    private final boolean success;
    private final String message;

    public Report(boolean success) {
        this.success = success;
        this.message = "empty message";

    }

    public Report(boolean success, String message) {
        this(success);
        this.message = message;
    }

    public boolean wasSuccessful() {
        return success;
    }

    public String getMessage() {
        return message;
    }
}

Затем вы можете решить, хотите ли вы получать общий отчет об успехе с помощью «wasSuccessful ()» или же вы хотите записать точную причину с помощью «getMessage ()».

Answer 1

Полезно ли для этой цели предоставить собственный класс отчета, который предлагает такую ​​функциональность?

"Полезность" субъективна.Если вышеописанное - это то, что хорошо решает вашу конкретную проблему, тогда, конечно, это полезно и может быть хорошим подходом.

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

Поэтому во многих ситуациях вы просто используете void методы.Как: только что возвращенный метод означает: «все хорошо».В противном случае, если возникла какая-либо проблема, метод выдает исключение.

Теперь, если, с другой стороны, у вас есть ситуации, когда метод может пройти или потерпеть неудачу, и оба результата в полном порядке (например, если какой-то метод проверяет, присутствует ли необязательный параметр )), то уверен: ваш подход может быть полезным.Вы просто позволяете добавлять новые Report объекты для каждого важного для вас вызова метода.И тогда тот, кто вызывает метод, может создать Report объекты и добавить их к некоторому контекстно-зависимому ReportCollector.

Но обратите внимание: проблема real в моих глазах: когда вы думаете о программном сборе (и использовании) такой «информации о прогрессе», тогда строки сообщений быстро превращаются впроблема.Есть веская причина, по которой люди иногда используют числовые идентификаторы ошибок: для программной обработки таких ситуаций.Струны несут смысл только для людей, которые их читают.

Ваш код мало что может сделать со строками.Помните: выполнение contains("this") или contains("that"), чтобы определить, как реагировать на ошибку (сообщения) позже, это настоящий анти-паттерн!

Answer 2

Вы можете попробовать использовать что-то вроде Либо паттерна. Он используется как Either<Report,Error> в каждый момент, когда у вас будет действительный отчет или объект с ошибками.