longまたはLongではなく、API（たとえば、従業員の誕生日フィールド）でDateクラスを使用する特定の理由はありますか？
これについては、 java-date-vs-calendarでいくつか説明されていますが、長い（または長い）方がはるかに単純に見える場合に、日付を使用する理由があるかどうかを具体的に知りたいと思います。
もちろん、TimeZoneとSimpleDateFormatterを使用してGUIで日付を解析および表示し、Calendarを使用して操作を実行しますが、この質問では、データモデル/APIでの日付の保存と表現のみに関心があります。
更新：日付を選択しない理由の1つの例は、変更可能であるということです。したがって、APIでDateを公開すると、呼び出し元はsetTime（long）を呼び出すことができ、これは基本的なカプセル化に違反しているようです。長いプロパティtimeInMillisecondsSinceEpochを呼び出して同じ情報を呼び出し元に伝達できるため、これは、日付を使用することで得られる明確さの利点を上回っているように見えます。
APIで日付を表すために整数を使用する場合、追加のドキュメントが必要になり、APIの使用が困難になる、余分な不要な複雑さのレイヤーが追加されます。
整数を使用することにより、基準日が何であるか、何を測定しているのか（たとえば、秒、ミリ秒、分など）をクライアントに知らせ、クライアントに変換を強制する必要があります。APIにDateオブジェクトを保持すると、IMOがよりシンプルで使いやすくなります。また、何らかの理由でパフォーマンスに深刻な影響がない限り、内部でより多くのコーディングを行う必要がある場合でも、APIに日付を保持することをお勧めします。これは、優れたAPIを優れたAPIにするものの1つです...クライアントにフープを飛び越えさせないでください。
個人的には、Javaの日時APIと同じくらい悪いのですが、私はを使用する傾向がありますDate。それはより意味的な価値を持っています。さらに、秒かミリ秒かを推測する必要はありません。
日付は数字ではなく、特定の時点です。それを数字で表すことができるという事実は、非表示にする必要がある実装の詳細です。
このDateクラスはAPIの一部であり、目的に合っている場合は有効なオプションです。Calendarクラスに置き換えられた多くの非推奨のメソッドが含まれているため、これらのメソッドの使用は避けてください。
答えは、何を達成する必要があるかによって異なります。日付で並べ替える必要がある場合は、alongで十分です。Date値はそれにある程度の読みやすさを追加しますが、それ以上の機能は追加しません。使用Dateすることも有害ではないため、読みやすさの要素を考慮する必要があります。
フィールドがプライベートになる場合は、実際にそれをlongとして保存し、以下を使用するゲッターとセッターを使用できますDate。
private long mDOB;
public Date getDOB () { return new Date(mDOB);}
public void setDOB (Date dob) { mDOB = dob.getTime(); }