問題タブ [marker-interfaces]

SelfComparable Interfaceリフレクションの練習をしているうちに、Collections授業で知りました

このインターフェイスは何に使用しますか?

JVMが次のようなマーカーインターフェースを内部的に処理する方法を誰かが説明してくれますか?

技術的には、クラスが serializable を実装する必要がある理由を知っています。理由は、ObjectOutputStream の writeObject メソッドが、オブジェクトの状態を書き込む前に「シリアライズ可能なインスタンス」を内部的にチェックするためです。

しかし、私の質問は、その必要性は何ですか? writeObject メソッドは、オブジェクト (状態を書き込む必要がある) がシリアライズ可能かどうかに関係なく、オブジェクトの状態を単純に書き込むことができますか?

wikiに従って、クラスはこのインターフェースを実装して、非一時的なデータ メンバーを ObjectOutputStream に書き込むことができることを示します。しかし、ここでも問題は、フィールドが一時的かどうかを判断するためだけにクラスがシリアライズ可能を実装する必要がある理由です。serialiable を実装していないクラスでも、シリアル化する必要があります (transient とマークされたフィールドを除く)。

オブジェクトを（インターフェースで）シリアライズ可能としてマークしても、そのオブジェクトが魔法のようにシリアライズ可能になるわけではありません。それはずっとシリアライズ可能でした。システムが自分で見つけた可能性のある何かを表現しただけなので、本当の正当な理由はわかりません連載は今のやり方です。

クラスをシリアル化するためにクラスがシリアル化可能なマーカーインターフェイスを実装する必要があるのはなぜですか?

宣言されたメソッド シグネチャは等しいようです。Collection を直接実装するのではなく、Set インターフェイスを導入する目的は何でしょうか? それとも、ここでは一種のマーカー インターフェイスですか?

ジェネリック シグネチャで使用するためだけにマーカー ダミー クラス (内部にメンバーを持たない) を作成することが良い考えかどうかを知りたいと思いました。

たとえば、次のインターフェイス シグネチャを考えてみましょう。

上記のインターフェイスを実装する具体的なクラスの例は次のとおりです。

上記の具体的なクラス定義では、クラスCreationContext (マーカー インターフェイスIContextを実装する) は、プロパティを持たないダミー クラスですが、同じ Customer クラスの他のバリデーターと区別するためだけに使用されますが、他のコンテキストは異なります。

このアプローチは良い考えですか？ダミーのメンバーのない空のクラスを使用するよりも優れた設計の選択肢はありますか?

上記の設計の目的は、同じエンティティに対して複数のバリデーター具象クラスを作成できるようにすることですが、さまざまなコンテキストに対して、それを依存性注入コンテナーと共に使用できるようにすることです。

次のコードは、さまざまなコンテキストでのこのようなバリデータの使用法を示しています。

お時間をいただき、ありがとうございました。

Java のマーカー インターフェイスについて混乱しています。

マーカー インターフェイスにメソッドがない場合、どこから呼び出されるか教えてください。これも明示的に実装する必要がありますか。