Le concept de conception de l'API de date et d'heure de Java est intéressant

Je n'ai pas utilisé l'API de date et d'heure (JSR 310 []) qui venait de Java SE 8 jusqu'à présent (puisque je n'étais pas particulièrement insatisfait de Joda-Time []), mais je l'ai recherchée l'autre jour. , J'ai trouvé le concept de design intéressant, je vais donc l'écrire.

Aperçu du package

Comme il existe de nombreux java.time.chrono [] qui contiennent des calendriers tels que le calendrier japonais, le nombre de classes semble être important.

java.time [] À première vue, il y a beaucoup de classes ci-dessous, mais beaucoup d'entre elles correspondent aux mots que vous utilisez habituellement, vous pouvez donc les avaler facilement.

• Année: [Année] []
• Mois: Month []
• Année: YearMonth []
• Date: MonthDay []
• Jour: DayOfWeek []
• Heures du jour
• Aucun fuseau horaire: LocalTime []
• Avec fuseau horaire (décalage): OffsetTime []
• La raison pour laquelle il n'y a pas de ZonedTime semble être que la date est nécessaire pour tenir compte de l'heure d'été [^ 2].
• Date: LocalDate []
• Date et l'heure
• Aucun fuseau horaire: LocalDateTime []
• Avec fuseau horaire (décalage): OffsetDateTime []
• Avec fuseau horaire (ID de zone): ZonedDateTime []
• Période
• Date: [Période] []
• Heure: [Durée] []
• Horloge: [Horloge] []
• Point dans le temps: Instant []
• Considérez-le comme un horodatage ou une abstraction de l'heure UNIX.
• Fuseau horaire
• Décalage heure, minute et seconde: [Décalage zone] []
• ID de zone (Asie / Tokyo, etc.): ZoneId []

Immuable

Il n'existe qu'une seule classe modifiable, java.time.format.DateTimeFormatterBuilder []. Il y a des choses qui ne doivent pas nécessairement être immuables, comme java.time.temporal.TemporalAdjuster [], mais elles vous disent gentiment (aigri votre bouche?) Que vous devriez les rendre immuables.

Exigences de mise en œuvre: Cette interface ne limite pas l'implémentation à être variable, mais il est fortement recommandé qu'elle soit immuable.

Convention de dénomination des méthodes

En plus des standards «get» et «to», les mots suivants sont utilisés comme préfixes de méthode. Vous pouvez également trouver «avec», «plus» et «moins» dans Joda-Time [].

• Obtenir une instance
• De ʻof`: int etc.
• from: depuis un autre objet
• Créer une autre instance
• ʻAt`: Combinez pour créer une autre instance (MonthDay + Year → LocalDate, etc.)
• with: Changez certaines parties pour créer une autre instance (comme ne changer que l'année avec LocalDate # withYear ())
• plus, minus: Ajouter et soustraire pour créer une autre instance

Évitez au maximum l'héritage

La plupart des classes n'utilisent pas l'héritage (héritent directement d'Object), à l'exception des classes d'exception. Ceci est en contraste avec Joda-Time Joda-Time.javadoc, qui utilisait beaucoup d'héritage. Même dans le cas de l'utilisation de l'héritage, la classe de base abstraite hérite directement de Object, et la sous-classe héritée est définitive pour éviter un héritage profond.

Éliminez complètement les classes existantes

Java.nio.Path [] introduit à partir de Java SE 7 peut être converti l'un à l'autre avec les java.io.File [] et toFile (), toPath () existants. Je vais. D'autre part, la conversion mutuelle avec l'ancienne API n'est implémentée que du côté de l'ancienne API.

J'ai le sentiment que ** vous (classe existante) êtes autorisé à marcher sur le sol de java.time **. Au début, il semble qu'aucune conversion mutuelle n'ait été préparée [^ 1], et j'ai même ressenti de la rancune contre l'ancienne API (ヽ ´ω`)

en conclusion

Il est également écrit en Java efficace, mais je sympathise avec lui car il a causé des bogues inattendus en ne le rendant pas immuable, et je pleurais parce qu'il a été hérité sans permission parce que je ne l'ai pas rendu définitif. Il y a de nombreux endroits à faire. Je vais l'utiliser activement à l'avenir.

[^ 1]: Astuces API de date et d'heure pour le japonais (ja) --notepad