次の検証シナリオを実装するための最良のパターン (可能であれば、4 本のギャングから) を考えています。
TLV (Type Length Value) と呼ばれるオブジェクトがあるとします。それは次のようになります。
public class TLV implements Serializable, TLVInterface {
private Type type;
private Length length;
private Value value; // the buffer may include sub-TLVs
…
getters/setters + other methods
…
}
このオブジェクトには、同じタイプのサブ オブジェクト、つまりサブ TLV を含めることができます。つまり、Value フィールドには、サブ TLV を含む可能性がある ByteBuffer があります。
ここで行う必要があるのは、特定のサブ TLV のみが既存の TLV の一部になる可能性があることを確認することです。つまり、メイン オブジェクト タイプに特定のサブタイプ、つまりサブ TLV のみを含めることができるというチェックを実装する必要があります。
TLV オブジェクトは、流体インターフェイスを使用して Builder パターンを使用して作成されます。その後、ツリーのようなもの、つまり tlv 内の tlv を構築するために Composite パターンを使用するというアイデアが生まれました。ただし、そのような構造を最適に検証する方法と、それが最適な設計であるかどうかについては、依然として疑問が残ります。
この質問は、適切な検証手法を実装する方法に関するものです。たとえば、統計的な関連付けを作成することを考えていました->各「タイプ」（整数）番号には、 List などのJava構造に静的に入力されたサブタイプ（整数）番号があります。次に、そのリストのクイック検索に基づいて、分析されたサブ TLV タイプが静的に事前に型指定されたリストにあるものと一致するかどうかを見つけることができます。これは機能しますが、TLVとJavaを使用するときに信頼できる、より優れた/よりスマートな検証設計パターン/手法があれば、私は好奇心旺盛でした。おそらく、他の人がその目的のためにすでに正確に使用しているパターンがあるでしょう。
私が最初にうまくいくと思った別の方法は、Java インターフェイスに依存し、クラスをある種のタグとしてタグ付けするためにそれらを使用し、サブ TLV の型を反復処理してそれらを構築し、それらが特定のインターフェイスを実装しているかどうかを調べることでした。これは、サポートするそれぞれの異なる TLV タイプを表す少なくとも 1 つのクラスを手動で作成する必要があることを意味します。私の場合、それらは何千もの可能性があり、悪夢になるコードになる可能性があるため、それは実現可能ではありません.
アイデア/テクニックは大歓迎です。