Хороший разум использовать java.util.Date в API

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

Об этом говорится в: java-date-vs-calendar, но я хотел бы знать конкретно, есть ли какое-либо обоснование использования Дат, когда длинный (или длинный) кажется намного проще.

Конечно, я бы использовал TimeZone и SimpleDateFormatter для синтаксического анализа и отображения дат в графическом интерфейсе и, возможно, Calendar для выполнения манипуляций, но я беспокоюсь только о хранении и представлении даты в модели данных /API в этом вопросе.

Обновление: Пример одной из причин, почему я не выбрал Date, это то, что она изменена. Поэтому, если я выставляю дату в моем API, вызывающие могут вызывать setTime (long), и это, по-видимому, является нарушением базовой инкапсуляции. Для меня это, похоже, перевешивает преимущества дополнительной ясности, связанные с использованием Date, поскольку я мог просто вызвать длинное свойство timeInMillisecondsSinceEpoch и передать ту же информацию вызывающим абонентам.

Ответы

Ответ 1

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

Ответ будет зависеть от того, что вам нужно сделать. Если вам просто нужно сортировать по дате, long будет более чем достаточно. Значение Date добавило бы к нему некоторую читаемость, но не больше функциональности. Использование Date также не будет пагубным, поэтому следует учитывать коэффициент удобочитаемости.

Если поле будет приватным, вы можете сохранить его как длинный и иметь геттер и сеттер, которые используют Date:

private long mDOB;

public Date getDOB () { return new Date(mDOB);}
public void setDOB (Date dob) { mDOB = dob.getTime(); }

Ответ 2

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

Используя целое число, вы должны сообщить клиенту, что такое базовая дата, что вы измеряете (например, секунды, миллисекунды, минуты и т.д.) и заставляете клиента выполнять преобразование. Сохранение объекта Date в вашем API упрощает и упрощает IMO. И если по какой-либо причине очень серьезные последствия для производительности, я бы предложил сохранить дату в вашем API, даже если вам нужно сделать больше кода внутри. Это одна из вещей, которая делает хороший API хорошим API... Не заставляя вашего клиента прыгать через обручи.

Ответ 3

Лично, так же плохо, как API даты и времени в Java, я склонен использовать Date. Он просто имеет большую смысловую ценность. Кроме того, вам не нужно угадывать, сколько секунд или миллисекунд.

Ответ 4

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

Ответ 5

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

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

Так что отладка и тестирование сложны. Peruse StackOverflow для доказательства этого.

Почему бы не отслеживать текст как серию октетов или даже бит? Потому что мы хотим, чтобы библиотеки обрабатывали сложные задачи и задачи (UTF-8, MacRoman, поиск, замена, обрезка и т.д.) Для нас. Аналогично, значения даты и времени должны обрабатываться как типы данных даты и времени.

Тем не менее, классы java.util.Date и .Calendar ужасны. Избегайте их, когда это возможно.

  • Теперь в Java 8 появился новый пакет java.time.
  • Если вы не можете использовать java.time, используйте Joda-Time.
  • Если вы не можете использовать Joda-Time, используйте строки в стандартном формате ISO 8601.