MainClassと呼ぶメインクラスを持つスタンドアロンのSwingアプリケーションがあります。このMainClassへの唯一のアクセスは、このクラスのmain（String args []）メソッドからです。つまり、このクラスは他のクラスでは使用されません。
MainClassのメンバーフィールドを「プライベート」にする必要がありますか？他のクラスがMainClassをインスタンス化することはないため、冗長であると主張しますが、別の経験豊富なプログラマーは、フィールドに「プライベート」のラベルを付けないことはJavaのベストプラクティスに違反していると主張します。
Java はオブジェクト指向です。
セッターとゲッターに貧弱なロジックが含まれていない場合、プライベートフィールドを作成しても意味がない場合があります。
実際、多くの開発者は、getter と setter を作成し、private フィールドを書き込むことはカプセル化であると考えています => 間違っています!
データをカプセル化することがなぜ重要なのか、特にどのようにカプセル化するのか? オブジェクト指向プログラミングは手続き型プログラミングとどう違うのですか?
この記事を読んでいくつかの答えを得ることができます: http://pragprog.com/articles/tell-dont-ask
そしてこれ: http://en.wikipedia.org/wiki/Law_of_Demeter
とこれを使った少し具体的な例: http://www.devdaily.com/java/java-law-of-demeter-java-examples
したがって、私によると、約 99% のケースで、フィールドはプライベート/パッケージまたは保護されている必要があり (ただし、フレームワークがそれを強制しない限り、決してパブリックではありません... まれです)、クラス メソッドをラップすることによってのみ操作されます。ほとんどの場合、getter/setter の 95% は役に立たないので削除できることに気付くのは驚くべきことです。
これはまったく異なる考え方であり、手続き型の考え方を止めるのは困難ですが、コードは非常に柔軟でクリーンになり、現実世界に最も近いものになります ;)
あなたが言った：
他のクラスが MainClass をインスタンス化しないため、冗長であると主張します
優れたデザインの鍵は、機能の作成を許可する限り、最も制限的であることだと思います. 開発者が寛大すぎると、プログラムは深刻な奇妙な衝突や動作につながる可能性があります。
開発者は、将来のプログラムがどうなるか (大規模なプログラムの場合) を予測し、将来の開発者がコンテキストのようなエラーを犯す可能性があることに注意する必要があります: メソッドの外側でクラスをインスタンス化しますmain。
private一般に、クラスの内部または外部から使用しているかどうかに関係なく、クラスのメンバー フィールドのみを使用する必要がありprotectedます。base class
外の世界が自分のフィールドに直接アクセスできるようにしたくありません... そうしないと、 の概念全体が壊れてしまいますEncapsulation。
つまり、あなたの特定のケースでも、それらをプライベートフィールドとして持つべきです..
そして、今のところそのクラスは外部からアクセスされませんが、安全側にいる方が良いでしょう..
Controlling Access to members of a Classで説明したように、パッケージ プライベートアクセスを意味する修飾子はありません。これにより、同じパッケージ内の他のクラスへの可視性が許可されます。それを望まない場合は、メンバーを明示的に非公開にします。