Как обеспечить ограничение целого числа в подсказке аргумента в Java

Question

Я новичок в Java после нескольких лет работы в PHP и пытаюсь понять некоторые из лучших практик и норм при работе с Java.

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

Например:

class Person() {
  private int age;

  public Person(int age) {
    if(age < 0) {
      throw new IllegalArgumentException();
    }
    this.age = age;
  }

  public int getAge() {
    return age;
  }
}

Или:

class Person() {
  private Age age;

  public Person(Age age) {
    this.age = age;
  }

  public int getAge() {
    return age.toInt();
  }
}


class Age() {
  private int age;

  public Age(int age) {
    if(age < 0) {
      throw new IllegalArgumentException();
    }
    this.age = age;
  }  

  public toInt() {
    return age;
  }
}      

Кроме того, во втором примере я преобразовываю объект Age в int в Person.getAge (), что удобно, но почему-то кажется неправильным, поскольку конструктор Person принимает объект Age. Есть мысли?

Спасибо!

Answer 1

Я думаю, что речь идет о применении ограничений, инкапсуляции поведения и т. Д. Вот что такое объектно-ориентированные языки. Он привык думать о мире меньше с точки зрения примитивов, таких как double, int и strings, и больше с точки зрения объектов, которые представляют лучшие абстракции, которые инкапсулируют и скрывают детали от клиентов.

Я бы тоже пошел за первый пример. Я также рекомендовал бы НЕ иметь элемент данных "возраст", так как он меняется каждый год. Лучше иметь дату рождения и рассчитать по ней текущий возраст.

Answer 2

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

Для вашего второго примера, я бы, вероятно, использовал метод Person.getAge, возвращающий объект Age вместо int. Опять же, в этом примере с игрушкой сложнее увидеть разницу, но возвращение int ощущается как слишком большая связь между Person и Age.

Answer 3

Я предпочитаю вторую версию с классом Age, поскольку она позволяет вам легче тестировать функциональность "age", не нуждаясь в экземпляре Peron. Также вы можете использовать Age для чего-то другого, например для Warrenty.

В общем, иметь int для Age - не очень хорошая идея, поскольку со временем вещи стареют. «Дата создания» имеет более общее назначение (внутри класса Age просто используйте Date вместо int).

Кроме того, вы сэкономите много времени, если выполните «бросить новое исключение IllegalArgumentException (« возраст не может быть <0, был: «+ возраст);») чтобы вы могли знать, какое значение имело оскорбительное значение (облегчает поиск неверных данных, когда вы знаете, что это за значение). </p>

Answer 4

Я бы также использовал первую версию, если ваша концепция Age не получила широкого распространения в вашем проекте, и в этом случае вы должны пойти вторым путем, а также быть последовательными и возвращать объект Age в getAge. У Age должен быть легкий доступ, чтобы получить инкапсулированный int.

Answer 5

Я думаю, что первый пример в порядке. Также вы должны описать выброшенное исключение в javadoc, чтобы пользователь вашего класса знал об этой функции поведения.

Answer 6

Первый тоже получит мой голос.

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

Исходя из названия поста, было бы неплохо подумать, следует ли сделать то же самое для верхнего предела. Я бы сказал, что (используя пример возраста), в зависимости от того, что задает возраст, верхний предел может быть лучше применен валидатором объекта. Проверка должна быть применена в некоторый момент, когда обратная связь с пользователем объекта может быть получена для реакции (например, перед сохранением), поскольку это не обязательно будет ошибка программирования, но ситуация, о которой пользователь должен сначала обратиться или получить уведомление.