0

インターフェイスを実装し、それを囲むクラスから値を返す内部プライベート クラスがあるコードを見つけました。囲んでいるクラスにインターフェイスを直接実装するのではなく、そのようなことを行うことに利益はありますか?

このようなもの：

public class Foo {
 public Whatever getWhatever() {  return new Boo(); }
 private Whatever boo;
 private int n;
 private class Boo implements Whatever {
  @Override int getN() { returns n; }
 }
}

多分それはここにある種のデザインパターンですか、それともこれに似たデザインパターンがあるのでしょうか?

4

5 に答える 5

3

1 つの重要な理由は、 の 1 つのインスタンスが のFoo多数の個別のインスタンスを作成して返すことができることですBoo。Fooそれがコレクション クラスでありBoo、イテレータであると想像すると、これにより、コレクションの実装の詳細を非公開に保ちながら、同じコレクションに対して複数の同時反復が可能になります。

于 2013-08-05T14:18:40.237 に答える
1

インターフェイスで複数のメソッドが宣言されている場合は、その手法を使用して、親クラスの API の汚染を回避し、代わりに単一のメソッドを提供してプライベート クラスのインスタンスを取得できます。クラス定義はより冗長になりますが、少なくとも IDE を使用している場合は、クライアント コードの読み書きが容易になると思います。

文脈によっては、他の用途があるかもしれません。

于 2013-08-05T14:18:55.770 に答える
0

ここで実際に使用される可能性のある 2 つのパターンがあります。

  1. ファサード パターン - 他の外部 API をラップまたは操作するときにこのようなことを行いましたが、自分のコードが外部 API インターフェイスで汚染されるのを避けたいと考えています。これにより、私のコードは外部 API を認識できなくなり、後で実装を変更したり、外部 API の醜さや混乱を隠したりすることができます。

  2. ファクトリ メソッド - メソッドでインスタンスを作成して返すことにより、インターフェイスのさまざまな実装を返したり、メモリを消費することなく既に作成されているインスタンスを再利用したりできます。

于 2013-08-05T14:17:48.480 に答える
0

これは、どのインターフェイスでも同じ利益です。メソッドがそのクラス内に存在することがわかります。いくつかのプライベート クラスを作成していて、それらで特定のメソッドを呼び出せるようにしたい場合は、そのインターフェイスを実装できます。

これが唯一のプライベートクラスである場合、直接収益にはなりません。ただし、インターフェイスではクラスが少なくともメソッドのスケルトンを実装している必要があるため、常に安全です。

于 2013-08-05T14:14:58.763 に答える