Хорошая практика: действительная собственность против метода isValid()?

Question

Какой подход проверки действительно прав? Первый из них:

public class Order { 
    ... 
    private boolean valid; 

    public boolean isValid() { 
     return valid; 
    } 

    public boolean setValid(boolean valid) { 
     this.valid = valid; 
    } 

    // getters, setters, etc. 
} 

где valid хранится как логическое значение в БД и установить с помощью Java кода где-нибудь еще, например, в DAO.

Или второй один:

public class Order { 
    ... 


    public boolean isValid() { 
     // some business code, e.g.: 
     return !orderItems.isEmpty(); 
    } 


    // getters, setters, etc. 
} 

, где мы не имеем valid значение keeped в БД, но каждый раз, когда это необходимо оно было рассчитано по требованию.

Какой подход лучше?

Answer 1

Структура Fisrt с setValid метод является уродливым. Я не могу себе представить использование метода setValid.
Если вы хотите использовать отдельные свойства, лучший способ заключается в использовании ленивой инициализации:

public class Order 
{ 
    ... 
    private Boolean valid; 

    public boolean isValid() 
    { 
     if (valid == null) 
     { 
      valid = !orderItems.isEmpty(); 
     } 
     // some business code, e.g.: 
     return valid; 
    } 
} 

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

Answer 2

Точного ответа нет. Это просто зависит. Зависит от дизайна вашего класса и бизнес-правил вашего бизнеса.

Например, если состояние заказа valid проверяет только на простое правило, такое как проверка текущего состояния ссылки на объект, тогда используйте его как метод с телом.

public class Order { 
    public boolean isValid() { 
     //validate current state of object reference 
     //re using your same example 
     return !orderDetail.isEmpty(); 
    } 
} 

Но в том случае, у вас есть бизнес-правило, требует порядок должен пройти для процесса проверки перед отправкой клиенту, и этот статус (и правильное описание) должно быть известно, в любой момент заявки , то наличие в базе данных поля valid является одним из способов его решения. Фактически, если бы это было так, было бы лучше сохранить поле valid как VARCHAR(X) и ограничить значения этого поля, используя enum OrderStatus. Но опять же, это зависит от дизайна вашего класса.

Answer 3

В первом примере вы лечите «действуют» как поле POJO, то есть так же, как геттерных() или сеттер() метода, за исключением того, потому что это булево это Исера() метод , Это нормально, так как я бы не нарушил эту фасоновую структуру. У геттеров и сеттеров не должно быть логики.

Insetad У меня был бы другой способ validate() который делает тяжелый материал.

validate() выполняет проверку и устанавливает допустимую переменную. isValid() возвращает последнюю выполненную проверку.

антипаттерн Я часто вижу это getXXXXX() метод, который занимает около 30 секунд, чтобы закончить, потому что она выполняет вычисления и хитов базы данных и вводит в заблуждение пользователю этого класса, как пользователь предполагает, что он является нормальным газопоглотитель в нормальный класс POJO.