質問が曖昧すぎて答えられないことを望みます。
リスト自体は必要なときにどこでも作成できます。静的フィールドとして必要な場合は、別のクラスでもそれを作成できます。
まったく同じクラスのフィールドとしてカスタム リストを追加するのはなぜでしょうか?
OOP におけるこのアプローチの長所と短所は何ですか?
これらのアプローチの結果の違いを説明していただけますか?
編集: 私は通常、クラスの複数のインスタンスを保存するために提案されているカスタム リストを使用します。他の人のコードを調べてみると、クラスが他のクラスと親子関係を持たないにもかかわらず、クラス自体の複数のインスタンスを格納するためのフィールドとして、同じクラス内のリスト オブジェクトとして定義されているアプローチが見られます。インフィニティミラー効果を思い出させます。それで、私は自分が何が悪いのか知りたかったのですここで歌ってください。
class Record {
String name;
String surname;
String phoneNumber;
ArrayList<Record> phoneBook;
}
class Main {
String x;
String y;
ArrayList<Record> phoneBook;
}
2
電話帳を含む Record という名前のクラスは正しく聞こえないため、デザインがオフになっています。このような再帰的な構造は場合によっては可能であり便利ですが、ここではそうではありません。
– カヤマン
2020 年 9 月 4 日 22:36
1
このアプローチ自体は問題なく、任意のツリー状/階層データ構造を表すために使用できます (ノードのリストを参照するノード、系図ツリー - 親と兄弟と子のリストを持つ個人、上司とリストを持つ従業員)部下など)
– ノーウェアマン
2020 年 9 月 4 日 23:00
------------------------
あなたの言うことに基づいて、Record クラスのインスタンスが 10 個あると仮定します。各クラスにそれら 10 個のインスタンスすべてのリストを保存すると仮定すると、実際には 100 個のインスタンスがあり、何をするかによっては、アプリケーションは aff である可能性があります影響を受けました。
一方、Record クラスのインスタンスが 10 個あるが、そのインスタンス自体をリストに保存するだけだとします。これでは意味がなく、まったく役に立ちません。
最後に、論理的に言えば、リストを作成するときはクラスの複数のインスタンスを保存し、各インスタンスのデータにアクセスできるため、クラス自体でリストを使用することはこの場合には役に立ちません。