IChronoLocalDate インターフェイス

定義

[Android.Runtime.Register("java/time/chrono/ChronoLocalDate", "", "Java.Time.Chrono.IChronoLocalDateInvoker", ApiSince=26)]
public interface IChronoLocalDate : IDisposable, Java.Interop.IJavaPeerable, Java.Lang.IComparable, Java.Time.Temporal.ITemporal, Java.Time.Temporal.ITemporalAdjuster

[<Android.Runtime.Register("java/time/chrono/ChronoLocalDate", "", "Java.Time.Chrono.IChronoLocalDateInvoker", ApiSince=26)>]
type IChronoLocalDate = interface
    interface IComparable
    interface IJavaObject
    interface IDisposable
    interface IJavaPeerable
    interface ITemporal
    interface ITemporalAccessor
    interface ITemporalAdjuster

派生

Java.Time.LocalDate

属性

RegisterAttribute

実装

IJavaObject IJavaPeerable IComparable ITemporal ITemporalAccessor ITemporalAdjuster IDisposable

注釈

高度なグローバリゼーションのユース ケースを対象とした、任意の時系列の時刻またはタイム ゾーンのない日付。

<b>ほとんどのアプリケーションでは、このインターフェイスではなく、メソッドシグネチャ、フィールド、変数を LocalDateとして宣言する必要があります</b>

ChronoLocalDateは、Chronology chronologyまたはカレンダー システムがプラグ可能な日付の抽象的な表現です。 日付は、最も一般的な実装がChronoFieldで定義されているTemporalFieldで表されるフィールドの観点から定義されます。 時系列は、カレンダー システムの動作方法と標準フィールドの意味を定義します。

<h2>このインターフェイスを使用する場合</h2> アプリケーションが複数のカレンダー システムを処理する必要がある場合でも、API の設計では、このインターフェイスではなく、 LocalDate の使用が推奨されます。

アプリケーションをグローバル化する自然な方法は、最初はカレンダー システムを抽象化しているように見える可能性があるため、この概念は最初は驚くかもしれません。 ただし、以下で説明するように、通常、カレンダー システムを抽象化することは間違ったアプローチであり、ロジック エラーが発生し、バグを見つけるのが困難になります。 そのため、 LocalDateではなく、このインターフェイスを使用することを選択するアプリケーション全体のアーキテクチャ上の決定と見なす必要があります。

<h3>考慮すべきアーキテクチャの問題</h3> これらは、アプリケーション全体でこのインターフェイスを使用する前に考慮する必要がある点の一部です。

1)このインターフェイスを使用するアプリケーションは、単に LocalDateを使用するのではなく、バグの確率が大幅に高くなります。 これは、開発中のカレンダー システムが開発時に認識されないためです。 バグの主な原因は、開発者が ISO カレンダー システムに関する日常的な知識から、任意のカレンダー システムに対処することを目的としたコードに前提を適用することです。 以下のセクションでは、これらの想定が問題を引き起こす可能性がある方法について説明します。このバグのリスクを軽減するための主要なメカニズムは、強力なコード レビュー プロセスです。 これは、コードの有効期間中のメンテナンスの追加コストとも見なす必要があります。

2) このインターフェイスは、実装の不変性を強制しません。 実装ノートは、すべての実装が不変でなければならないことを示していますが、これを強制するコードまたは型システムには何もありません。 したがって、 ChronoLocalDate を受け入れるように宣言されたメソッドは、不適切または悪意を持って記述された変更可能な実装に渡される可能性があります。

3)このインターフェイスを使用するアプリケーションは、時代の影響を考慮する必要があります。 LocalDate は、 getYear() がプロレプティック年を確実に返すことで、ユーザーを時代の概念から守ります。 この決定により、開発者は LocalDate インスタンスを、年、月、日の 3 つのフィールドで構成されていることを確認できます。 これに対し、このインターフェイスのユーザーは、日付は、時代 (年号)、年号(年号)、月単位、および月単位の 4 つのフィールドで構成される日付と考える必要があります。 余分な時代 (年号) フィールドは忘れ去られていますが、任意のカレンダー システムの日付にとって非常に重要です。 たとえば、日本の暦体系では、時代 (年号) は天皇の治世を表します。 1つの治世が終わり、別の治世が始まるたびに、年号は1にリセットされます。

4)2つのシステム間で日付を渡すための唯一の合意された国際標準は、ISOカレンダーシステムを必要とするISO-8601標準です。 アプリケーション全体でこのインターフェイスを使用すると、必然的にネットワークまたはコンポーネントの境界を越えて日付を渡す必要があり、アプリケーション固有のプロトコルまたは形式が必要になります。

5) データベースなどの長期的な永続化は、ほとんどの場合、ISO-8601 カレンダー システム (または関連する Julian-Gregorian) の日付のみを受け入れます。 他のカレンダー システムで日付を渡すと、永続化との対話の複雑さが増します。

6) ほとんどの場合、次の最後のセクションで説明するように、アプリケーション全体で ChronoLocalDate を渡す必要があります。

<h3>複数カレンダーシステムコードのバグを引き起こすfalseの前提</h3> 上記のように、任意のカレンダーシステムで日付を使用して操作しようとすると、考慮すべき多くの問題があります。 これらは重要な問題の一部です。

月の日を照会し、値が 31 を超えないと想定するコードは無効です。 カレンダー システムによっては、数か月で 31 日を超えるものもあります。

日付に 12 か月を追加し、年が追加されたことを前提とするコードは無効です。 一部のカレンダー システムでは、コプトやエチオピックの 13 など、月数が異なります。

日付に 1 か月を追加し、年の月の値が 1 ずつ増加するか、または次の年に折り返されることを前提とするコードは無効です。 一部のカレンダー システムでは、ヘブライ語など、1 年の月数が可変です。

1 か月を追加し、2 番目の 1 か月を追加し、その日が元の値に近いままであることを前提とするコードは無効です。 一部のカレンダー システムでは、最も長い月の長さと最短の月の長さの間に大きな違いがあります。 たとえば、コプトまたはエチオピックには、30 日の 12 か月と 5 日間の 1 か月があります。

7 日を加算し、1 週間が追加されたことを前提とするコードは無効です。 一部のカレンダー システムには、フランス革命など、7 日以外の週があります。

date1の年がdate2年より大きいため、date2後date1が無効であることを前提とするコード。 これは、元号を参照する場合、すべての暦システムでは無効であり、特に新しい天皇の治世で元号の年が再開される日本の暦システムには正しくありません。

1 年の月と日の 1 を年の開始として扱うコードは無効です。 すべてのカレンダー システムが、月の値が 1 の年を開始するわけではありません。

一般に、カレンダー システムが開発時に不明な場合、日付を操作したり、日付のクエリを実行したりしても、バグが発生する可能性があります。 このため、このインターフェイスを使用するコードに追加のコード レビューが適用される必要があります。 また、通常、このインターフェイスの種類を回避するアーキテクチャ上の決定が正しい理由でもあります。

<h3>代わりに LocalDate を使用する</h3> アプリケーション全体でこのインターフェイスを使用する主な代替手段は次のとおりです。 <ul><li>LocalDateの観点から日付を参照するすべてのメソッドシグネチャを宣言します。 <li> ユーザー プロファイルに時系列 (カレンダー システム) を格納したり、ユーザー ロケール <li>印刷中にユーザーの優先カレンダー システムとの間で ISO LocalDate を変換したり、 </ul から時系列を参照したりしません> このアプローチでは、グローバル化されたカレンダー システムの問題をローカライズの問題として扱い、UI レイヤーに限定します。 このアプローチは、Java プラットフォームの他のローカライズの問題に対応しています。

前述のように、カレンダー システムのルールがプラグ可能な日付に計算を実行するには、スキルが必要であり、推奨されません。 さいわい、任意のカレンダー システムで日付に対して計算を実行する必要性は非常にまれです。 たとえば、ライブラリ ブックのレンタル スキームのビジネス ルールでは、1 か月間のレンタルが許可される可能性は非常に低く、その月の意味はユーザーの優先カレンダー システムに依存します。

任意のカレンダー システムの日付に対する計算の主なユース ケースは、表示とユーザー操作のために月単位の予定表を生成することです。 繰り返しますが、これは UI の問題であり、UI レイヤーのいくつかのメソッド内でのみこのインターフェイスを使用することが正当化される可能性があります。

ISO 以外のカレンダー システムで日付を操作する必要があるシステムの他の部分では、ユース ケースでは通常、使用するカレンダー システムが指定されます。 たとえば、アプリケーションでは、日付を操作する必要がある可能性がある次のイスラムまたはヘブライの休日を計算する必要があります。 この種のユース ケースは、次のように処理できます。<ul><li>メソッドに渡される ISO LocalDateから開始<li>代替カレンダー システムに日付を変換します。 これは、このユース ケースでは、任意の<ではなく既知>計算<li>LocalDate</ul>低レベルのフレームワークまたはライブラリを記述する開発者も、このインターフェイスを避ける必要があります。 代わりに、2 つの汎用アクセス インターフェイスのいずれかを使用する必要があります。 読み取り専用アクセスが必要な場合は TemporalAccessor を使用し、読み取り/書き込みアクセスが必要な場合は Temporal を使用します。

1.8 で追加されました。

Javaドキュメント。

このページの一部は、によって作成および共有され、に記載されている条件に従って使用される作業に基づく変更です。