Почему API даты Java (java.util. Дата.Calendar) такая путаница?
Одно из предложений от Microsoft TechEd сессии на безопасности, которую я посетил, чтобы выполнить все вызовы через сохраненный procs и запретить доступа непосредственно к таблицам. Этот подход был тарифицирован как обеспечение дополнительной безопасности. Я не уверен, стоит ли это того только для безопасности, но если Вы уже используете сохраненный procs, это не могло бы причинить боль.
3 ответа
Кто-то сформулировал это лучше, чем я мог бы сказать:
- Класс
Датапредставляет определенный момент времени с миллисекундами точность. Дизайн этого класса - очень плохая шутка, отрезвляющая пример того, как ошибаются даже хорошие программисты. Большинство методов в Date теперь устарела и заменена методами в классах ниже.Класс
Calendar- это абстрактный класс для преобразования междуDateобъект и набор целочисленных полей, таких как год, месяц, день и час.Класс
GregorianCalendar- единственный подклассCalendarв JDK. Он выполняет преобразование даты в поля для календарной системы в общего пользования. Sun предоставила лицензию на это сверхтехнологичное барахло от Taligent - отрезвляющий пример того, как облажались средние программисты.
из FAQ программистов Java , версия от 07.X.1998, автор Питер ван дер Линден - эта часть была удалена из более поздних версий.
Как из-за изменчивости многие ранние классы JDK страдают от этого ( Point , Rectangle , Dimension , ...). Некоторые говорят, что неправильная оптимизация.
Идея в том, что вы хотите иметь возможность повторно использовать объекты ( o.getPosition (). X + = 5 ), а не создавать копии ( ] o.setPosition (o.getPosition (). add (5, 0)) ), как вы имеете дело с неизменяемыми объектами. Это могло быть даже хорошей идеей для ранних виртуальных машин, хотя, скорее всего, этого не было для современных виртуальных машин.
Ранние API-интерфейсы Java - не что иное, как продукт своего времени. Неизменяемость стала популярной концепцией только спустя годы после этого. Вы говорите, что неизменность «очевидна». Это могло быть правдой сейчас, но не тогда. Точно так же, как внедрение зависимостей сейчас «очевидно», но не 10 лет назад.
Одно время создание объектов Calendar было дорогостоящим.
Они остаются такими же из соображений обратной совместимости. Что, возможно, более прискорбно, так это то, что после того, как ошибка была обнаружена, старый класс не стал устаревшим, и были созданы новые классы даты / времени для всех будущих API. В некоторой степени это произошло с внедрением JDK 8 API, подобного JodaTime ( java.time , JSR 310), но на самом деле слишком поздно.
Время само по себе нелегко измерить и с ним справиться. Достаточно взглянуть на длину статьи в Википедии о времени . Кроме того, есть разные представления о самом времени: абсолютная временная точка (как константа), временная точка в определенном месте, временной диапазон, разрешение времени ....
Я помню, когда я увидел java.util.Date в первый раз (JDK 1.0?) я был действительно этому счастлив. В языках, которые я знал, такой особенности не было. Я не думал о преобразовании времени и т. Д.
Я думаю, что это беспорядок, потому что все, что изменяется, оставляет беспорядок, если вы эволюционируете от одного уровня понимания (XMLGregorianCaldender vs. Date) и требований (Наносекунды, после 2030 года) до более высокого уровень, но сохраняя старое нетронутым. И java.util.Date не является исключением. Достаточно взглянуть на подсистему ввода-вывода или переход от AWT к Swing ...
И из-за этого «мы должны иногда нажимать кнопку сброса». (кто это сказал, кстати?)