Noda Time vs Joda Time?

Question

Noda Time vs Joda Time?

#1 da (30 voti)

19

Nella Guida dell'utente di Noda Time , la logica stati della sezione:

the public API has been largely rewritten, both to provide an API which is more idiomatic for .NET, and also to rectify some of the Joda Time decisions which the Noda Time team view as "unfortunate". (Some of these are simply due to having different goals; others I'd argue are really mistakes.)

Quali sono queste decisioni che sono diverse / migliori? Questo non conterebbe le differenze solo per la sintassi del linguaggio, ma includerebbe qualsiasi cosa fatta per rendere gli utenti meno propensi a fare un errore di programmazione (usabilità della libreria).

libraries time joda-time

posta Neal Tibrewala 22.02.2013 - 23:46

fonte

1 risposta

Leggi altre domande sui tag libraries time joda-time

Java e .NET: perché vengono utilizzati diversi algoritmi di ordinamento per impostazione predefinita? Sono sviluppatori uno stakeholder in un sistema

score 30 · Accepted Answer

Il punto migliore da cui iniziare è probabilmente la sezione "filosofia di progettazione" della guida per l'utente. Ma per evidenziare specifiche differenze tra Noda Time e Joda Time:

Noda Time mantiene molto più del suo codice interno. Ciò lo rende meno flessibile, in quanto non puoi creare il tuo sistema di calendario personale, ma significa anche che l'API è più semplice da imparare e da usare.
Nullity è quasi sempre un errore in Noda Time. Non più "se si passa in null per un fuso orario, utilizzeremo semplicemente l'impostazione predefinita di sistema". Devi essere esplicito.
Parlando di valori predefiniti ... non usiamo l'orologio di sistema come predefinito. Abbiamo un'interfaccia IClock separata con un'implementazione SystemClock , ma per impostazione predefinita non è "l'ora corrente".
Oltre a specifiche classi di builder, tutto è immutabile. Penso che MutableDateTime (et al) in Joda Time sia stato un errore.
Abbiamo separato il sistema del calendario e il fuso orario l'uno dall'altro, poiché sono preoccupazioni molto diverse. Quindi un LocalDate conosce il sistema di calendario che usa, ma non il fuso orario, per esempio.
Il modo di risolvere i valori di data / ora locali con valori di data / ora suddivisi in zone è più vicino a JSR-310 rispetto a Joda Time. Non gestiamo semplicemente le ambiguità / i tempi saltati in un modo particolare: facciamo in modo che l'utente dica ciò che vuole.
Joda Time ha varie posizioni in cui tenta di indovinare cosa vuoi da un'API debolmente tipizzata (ad es. nuovo Instant(Object) ). Noda Time lo evita il più possibile, è molto più esplicito.
Noda Time è più rigido in quale tipo di aritmetica è possibile eseguire su quali tipi. Quindi, ad esempio, non puoi aggiungere Period a ZonedDateTime , perché ci sono stranezze in merito alle transizioni in cui è possibile salvare l'ora legale. Incoraggiamo invece gli utenti a convertire in LocalDateTime , eseguono comunque molta aritmetica in un contesto non a zone e poi riconvertono.
Noda Time utilizza l'ereditarietà in misura inferiore - le gerarchie in Joda Time sono estremamente profonde e complicate. Il fatto che un sacco di Noda Time sia basato su tipi di valore lo impone comunque, ma ci sono alcuni punti in cui stiamo ancora usando l'ereditarietà della classe, ma sono riuscito a comprimere la gerarchia dell'eredità in modo significativo ... spesso a spese di flessibilità che non ho ritenuto utile:)