プライベートクラスからパブリッククラスのメソッド/フィールドへのアクセス

Question

同じファイル内のプライベートクラスのパブリッククラスのプライベートメソッド/フィールドにアクセスすることは悪いことですか "ダム"ですか？私の場合、私はGUIのコンポーネントをパネル（GridBagLayout）に追加するメソッドを持っていますので、このためのメソッドを作成しました。しかし私は3つのパネルを持っているので、各プライベートクラスにaddComponent-methodを作成する代わりに、私はpublicクラスのprivateメソッドaddComponentを持っています。

これは私のクラスの概要は次のとおりです。

• RegisterQuestionGUI（パブリック）
  • このクラスは、そのうちの一つがaddComponentという名前のプライベートな方法で、多くのメソッドを持っています。
  • また、JPanelを拡張する3つのプライベートクラスがあり、これらのクラスはすべて同じ方法でaddComponentを使用します。

だから、戻って私の質問に、これはそれをやって良い/悪い方法ですか？

ありがとうございます。

Answer 1

一般に、私はそれに問題はありません。プライベート内部クラスは外部クラスの実装の一部であるため、カプセル化は壊れません。 OTOHは複製を取り除くことが良いことです。

AFAIKこのイディオムは、何度もクラスライブラリで使用されています。コレクションフレームワークにIteratorを実装するときに発生します。その典型的な使用法は、次のような共通の特徴持っている傾向がある：

• あなたは具体的な実装クラスを公開することなく、特定のインターフェイスを実装する必要があるが、しかし
• 実装には、いくつかの公共のクラスに密接に結合している（実際には2を作りますa 構成要素）。

プライベート内部クラスのインターフェイスを実装すると、両方の制約を一度にうまく満たし、2つのクラスの論理的な依存関係を明示的にし、実装クラスをカプセル化します。

Answer 2

私はそれが完全に受け入れられたと言いたい - 私は過去に同様のことをした。内部クラスからのプライベート変数へのアクセスは、理由のために許可されていますが、多くの状況（これだけではありません）ではそうするのが理にかなっています。

Answer 3

優れています。

特定のインターフェース（EventListenerなど）を実装する必要があるため、プライベートクラスが必要です。あなたは彼らを内部クラスにするのは、外部クラスを超えて無関係であるからです。しかし、外部クラスのプライベートユーティリティを作成するコードを再利用します。だから、あなたは良いプログラマです。

Answer 4

これは一般的に問題ありません。しかし、これらのJPanelクラスが何であるかに応じて、別のクラスからそれらを壊すほうが意味があります。おそらく、同じインタフェースを実装して、RegisterQuestionGUIが同じ方法でそれらとやり取りできるようにすることさえできます。

Answer 5

プライベート内部クラスは、パブリック "外部"クラスの一部です。したがって、外部クラスのプライベートメンバーへのアクセスは完全に受け入れられます。

Answer 6

です。

プライベートクラスが簡単なヘルパーである場合、それらをメインクラスの実装の一部として考えるのは妥当かもしれません。それは非自明な入れ子になったクラスがある

• ：場合

  ただし、プライベートクラスは、それを含むクラスの唯一の非プライベートメソッドにアクセスすることもできます。

• いつかネストされたクラスを移動したい場合は、たとえば、トップレベルのクラスにすることができます。