에서 노다 시간 사용 설명서 , 근거 섹션 상태 :
공용 API는 .NET에 더 관용적 인 API를 제공하고 Noda Time 팀이 “불행한”것으로 간주하는 Joda Time 결정 중 일부를 수정하기 위해 크게 재 작성되었습니다. (이들 중 일부는 단순히 다른 목표를 가지고 있기 때문에, 다른 사람들은 실제로 실수라고 주장합니다.)
다른 / 더 나은 결정은 무엇입니까? 언어 구문의 차이 만 계산하지는 않지만 사용자가 프로그래밍 오류 (라이브러리 유용성)를 덜 발생시키기 위해 수행 한 모든 작업을 포함합니다.
답변
시작하기 가장 좋은 곳은 아마도 사용자 안내서 의 “디자인 철학” 섹션 일 것입니다. 그러나 Noda Time과 Joda Time의 구체적인 차이점 을 설명하려면 다음을 수행하십시오.
-
Noda Time은 훨씬 더 많은 코드를 내부에 보관합니다. 따라서 실제로 자체 캘린더 시스템을 만들 수 없다는 점에서 유연성이 떨어집니다. 또한 API는 배우고 사용하기가 더 간단합니다.
-
Nullity는 Noda Time에서 거의 항상 오류입니다. 더 이상 “시간대에 null을 전달하면 시스템 기본값 만 사용합니다.” 명시 적이어야합니다.
-
기본값으로 말하면 … 시스템 시계를 기본값으로 사용하지 않습니다. 구현
IClock과 별도의 인터페이스가SystemClock있지만 기본값은 “현재 시간”입니다. -
특정 빌더 클래스 외에는 모든 것이 불변입니다.
MutableDateTimeJoda Time의 (et al)은 실수 라고 생각 합니다. -
캘린더 시스템과 시간대는 서로 매우 다른 관심사이므로 서로 분리되어 있습니다. 따라서
LocalDate예를 들어 시간대가 아닌 사용하는 캘린더 시스템에 대해 알고 있습니다. -
지역 날짜 / 시간 값을 존 날짜 / 시간 값으로 해석하는 방법은 Joda Time보다 JSR-310에 더 가깝습니다. 우리는 특정한 방식으로 모호성 / 건너 뛰기 시간을 처리하는 것이 아니라 사용자가 원하는 것을 말하게합니다.
-
Joda Time에는 약한 유형의 API (예 : new
Instant(Object)) 에서 원하는 것을 추측하려는 다양한 위치가 있습니다 . Noda Time은 가능한 한 이것을 피합니다. 훨씬 명확합니다. -
Noda Time은 어떤 유형에 대해 어떤 종류의 산술을 수행 할 수 있는지가 더 엄격합니다. 예를 들어, 일광 절약 전환 주위에 문제가 생길 수 있기 때문에
Period를에 추가 할 수 없습니다ZonedDateTime. 대신 사용자는로 변환하고 영역LocalDateTime이없는 컨텍스트에서 원하는 산술을 많이 수행 한 다음 다시 변환하도록 권장합니다 . -
Noda Time은 상속을 덜 사용합니다. Joda Time의 계층 구조는 매우 깊고 복잡합니다. 많은 Noda Time이 실제로 가치 유형을 기반으로한다는 사실은 실제로 어쨌든 이것을 시행하지만 여전히 클래스 상속을 사용하는 곳이 있지만 상속 계층 구조를 크게 축소 할 수 있습니다. 내가 가치가 없다고 생각한 유연성