Pourquoi l'API de date Java (java.util.Date, .Calendar) est-elle si désordonnée?

Question

Comme la plupart des gens sont douloureusement conscients de maintenant, l'API Java pour la gestion des dates du calendrier (en particulier les classes java.util.Date et java.util.Calendar) sont un gâchis terrible.

Du haut de ma tête:

• date est mutable
• La date représente un horodatage, pas une date
• pas de manière facile de convertir entre les composants de date (jour, mois, année .. .) et date
• Calendrier est maladroit d'utiliser, et tente de combiner différents systèmes de calendrier dans une classe

This post résume assez bien, et JSR-310 aussi expire ces problèmes.

Maintenant, ma question est la suivante:

Comment ces classes ont dans le SDK Java? La plupart de ces problèmes semblent assez évidents (en particulier la date étant mutable) et auraient dû être faciles à éviter. Alors, comment est-ce arrivé? Pression de temps? Ou les problèmes sont-ils évidents seulement rétrospectivement? Je réalise que ce n'est pas strictement une question de programmation, mais je trouverais intéressant de comprendre comment la conception d'API pourrait aller si mal. Après tout, les erreurs sont toujours une bonne opportunité d'apprentissage (et je suis curieux).

Answer 1

Quelqu'un a dit mieux que je ne pourrais jamais dire:

• classe Date représente un instant précis dans le temps, avec une précision milliseconde . Le design de cette classe est une très mauvaise blague - un exemple qui montre à quel point même les bons programmeurs bousillent. La plupart des méthodes de Date sont maintenant obsolètes, remplacées par des méthodes dans les classes ci-dessous.

• La classe Calendar est une classe abstraite permettant de convertir un objet Date en un ensemble de champs entiers tels que l'année, le mois, le jour et l'heure. La classe GregorianCalendar est la seule sous-classe de Calendar dans le JDK. Il effectue les conversions Date-à-champs pour le système de calendrier en l'utilisation courante.Sun a accordé une licence à cette entreprise indésirable de Taligent - un exemple qui donne à réfléchir sur la façon dont les programmeurs moyens bousillent.

de programmeurs Java FAQ, version à partir 07.X.1998, par Peter van der Linden - cette partie a été retirée de versions ultérieures si. En ce qui concerne la mutabilité, beaucoup de classes JDK précoces en souffrent (Point, Rectangle, Dimension, ...). Optimisations mal dirigées, j'en ai entendu dire. L'idée est que vous souhaitiez être en mesure de réutiliser des objets (o.getPosition().x += 5) plutôt que de créer des copies (o.setPosition(o.getPosition().add(5, 0))) comme vous le feriez avec des objets immuables. Cela peut même avoir été une bonne idée avec les premières machines virtuelles, alors que ce n'est probablement pas le cas avec les machines virtuelles modernes.

Answer 2

Les premières API de Java ne sont rien de plus qu'un produit de leur temps. L'immutabilité n'est devenue un concept populaire que des années plus tard. Vous dites que l'immutabilité est "évidente". Cela pourrait être vrai maintenant mais ce n'était pas alors. Tout comme l'injection de dépendance est maintenant «évidente» mais il n'y a pas 10 ans.

Il était également coûteux de créer des objets Calendrier.

Ils restent ainsi pour des raisons de compatibilité descendante. Ce qui est peut-être plus regrettable, c'est qu'une fois l'erreur réalisée, l'ancienne classe n'était plus obsolète et de nouvelles classes date/heure ont été créées pour toutes les API à venir. Cela a dans une certaine mesure eu lieu avec l'adoption d'un JodaTime API JDK 8 (java.time, JSR 310), mais c'est vraiment trop peu trop tard.

Answer 3

Le temps n'est pas facile à mesurer et à manipuler. Il suffit de regarder la longueur de l'article wikipedia sur time. Et puis, il y a différentes compréhensions sur le temps lui-même: un point de temps absoulte (comme une constante), un point de temps à un certain endroit, une plage de temps, la résolution du temps. vu java.util.Date la première fois (JDK 1.0?) j'étais vraiment heureux à ce sujet. Les langues que je connaissais n'avaient pas cette fonctionnalité. Je ne pensais pas à la conversion du temps, etc.

Je pense que c'est le bazar, parce que tout ce qui change laisse un désordre si vous évoluez d'un niveau de compréhension (XMLGregorianCaldender vs Date) et les exigences (Nanosecondes, passé 2030) à niveau supérieur, mais en gardant le vieil intacte. Et java.util.Date n'est pas une exception. Il suffit de regarder le sous-système d'E/S ou la transition de AWT à Swing ...

Et à cause de cela, "nous devrions parfois appuyer sur le bouton de réinitialisation." (Qui a dit que, btw.?)

Answer 4

Vous pourriez trouver le post suivant intéressant. Il explique à peu près comment la classe Calendar est entrée dans l'API Java en premier lieu, et apporte un éclairage sur les origines de la classe de date.

The Seven Habits of Highly Dysfunctional Design