Noda Time vs Joda Time?

У Посібнику користувача Noda Time в розділі обгрунтування зазначено:

публічний API був значною мірою перероблений, як для надання API, який є більш ідіоматичним для .NET, так і для виправлення деяких рішень Joda Time, які команда Noda Time розглядає як "нещасливі". (Деякі з них просто через те, що вони мають різні цілі; інші, як я стверджую, - це дійсно помилки.)

Які ці рішення є різними / кращими? Це не вважатиме різниці лише для синтаксису мови, але включатиме все, що робиться для того, щоб користувачі могли менше помилитися з програмуванням (зручність використання бібліотеки).

Найкраще місце для початку - це, мабуть, розділ "філософія дизайну" в посібнику користувача. Але викласти конкретні відмінності між Noda Time та Joda Time:

• Noda Time зберігає набагато більше внутрішнього коду. Це робить його менш гнучким, оскільки ви фактично не можете створити свою власну календарну систему - але також означає, що API простіший у навчанні та використанні.

• Недійсність майже завжди є помилкою в Noda Time. Більше не "якщо ви перейдете в нуль для часового поясу, ми просто використаємо системний стандарт". Вам потрібно бути явним.

• Якщо говорити про за замовчуванням, ми не використовуємо системний годинник за замовчуванням. У нас є окремий IClockінтерфейс з SystemClockреалізацією, але нічого не за замовчуванням "поточного часу".

• Крім конкретних класів будівельників, все незмінне. Я думаю MutableDateTime(та ін.) У Joda Time були помилкою.

• Ми відокремили систему календаря та часовий пояс один від одного, оскільки вони насправді дуже різні. Тож LocalDateзнає про систему календарів, яку вона використовує, але не часовий пояс, наприклад.

• Спосіб вирішення локальних значень дати / часу до зонованих значень дати / часу ближче до JSR-310, ніж Joda Time. Ми не просто обробляємо неоднозначність / пропущені часи якимось певним чином: ми змушуємо користувача говорити те, що вони хочуть.

• Joda Time має різні місця, де він намагається відгадати, що ви хочете від слабо типізованого API (наприклад, нового Instant(Object)). Noda Time уникає цього, наскільки це можливо - це набагато явніше.

• Час Noda суворіший у тому, яку арифметику ви можете виконувати на яких типах. Так, наприклад, ви не можете додати Periodдо ZonedDateTime, тому що є якісь збочення навколо Daylight Saving переходів , які могли б накоїти. Натомість ми заохочуємо користувачів перетворюватися на те LocalDateTime, скільки арифметики вони хочуть у незонованому контексті, а потім конвертувати назад.

• Noda Time використовує спадщину набагато менше - ієрархії в Joda Time надзвичайно глибокі та складні. Те, що багато Noda Time засноване на типах цінностей, насправді застосовує це все-таки, але є деякі місця, де ми все ще використовуємо спадкування класів, але мені вдалося значно зруйнувати ієрархію спадкування ... часто за рахунок гнучкості, яку я не вважав вартим :)