なぜファーストクラスのコレクションを使用する必要があるのですか？

The ThoughtWorks AnthologyのJeff Bay ^（RTF）によるObject Calisthenicsの規則4に従って、「ファーストクラスのコレクションを使用する」ことをお勧めします。

ルール4：ファーストクラスコレクション

このルールの適用は簡単です。コレクションを含むクラスには、他のメンバー変数を含めないでください。各コレクションは独自のクラスにラップされるため、コレクションに関連する動作にはホームがあります。フィルタがこの新しいクラスの一部になることがあります。また、新しいクラスは、2つのグループを結合したり、グループの各要素にルールを適用するなどのアクティビティを処理できます。

これから理解できるのは、コレクションをラップアップする別のクラスを使用し、そのコレクションのデータを追加、削除、変更するメソッドを使用する必要があるということです。

そして、どのデータ型がコレクションに入れられ、何が出てくるかを確認するためにこれが必要です。

（適用可能な言語で）ジェネリックコレクションを使用する場合、この規則に従う必要がありますか？

重要な意味が欠けている場合は、明確にしてください。

型安全性は、ファーストクラスのコレクションを使用する非常に小さな理由です。リンクから：

ルール4：ファーストクラスコレクションこのルールの適用は簡単です。コレクションを含むクラスには、他のメンバー変数を含めないでください。各コレクションは独自のクラスにラップされるため、コレクションに関連する動作にはホームがあります。フィルタがこの新しいクラスの一部になることがあります。また、新しいクラスは、2つのグループを結合したり、グループの各要素にルールを適用するなどのアクティビティを処理できます。

ここでの考え方は、検索、フィルタリング、検証、またはコレクションのセマンティクスの追加/削除/反復を超える何かを見つけた場合、コードはそれを独自のクラスに入れるように求めているということです。（検索後に）1つの値のみを更新する必要がある場合、おそらくコレクションクラスに含まれます。

この理由は非常に単純で、コレクションは渡される傾向があります。すぐに、4つの異なるクラスに独自のSearchByID()メソッドがあります。またはMap<Integer, String>、そのマップに保存されているもののコンテキストを取り除いたような戻り値を取得します。一流のコレクションは、単一のソースファイルを必要とする単純なソリューションです。実際には、それらが適切に配置されると（ユニットテストも非常に簡単に記述できます）、SearchByIDintの代わりにGUIDを取得する必要がある場合など、コレクションを扱う変更を簡単に処理できます。

...コレクションをラップアップする別のクラスを使用し、そのコレクションのデータを追加、削除、変更するメソッドを使用します

これは、コレクションに格納されているオブジェクトのタイプを保証するだけでなく、コレクションの不変条件も保証します。

ツリー（赤黒、AVLなど）は順序に敏感であり、適切な場合、その動作はリバランスに依存します。ハッシュテーブルのパフォーマンスも、適切な再ハッシュに依存します。ハッシュマップに挿入するたびに負荷率を確認することを忘れないようにしたいですか？

FWIW、これについてのテキストは非常に明確です（そして、あなたの質問にすべてを編集しますので、誰もそのRTFをダウンロードする必要はありません）：

各コレクションは独自のクラスにラップされるため、コレクションに関連する動作にはホームがあります

型（つまりジェネリック）とは何の関係もありません。コレクションの動作とデータの関連付けとは関係ありません。

ジェネリックをサポートする言語を使用している場合、単純な答えは「いいえ」です。言語機能自体がこれでかなり良い仕事をするので、型をチェックする必要がないので（私のJavaジェネリックの経験から）。

しかし、言語から与えられたデータ構造をカスタマイズしたい場合は、元のデータ構造の周りにラッパークラスを作成し、独自のAPIを公開し、元のデータ構造の基礎となる実装を使用できます。