キーワードが同じパッケージからのフィールド/メソッドへのアクセスを許可する正当な理由はありますかprotected(修飾子が許可しないのと同じ方法で)? Java 言語に package-private 可視性が含まれているのはなぜですか? 私の意見では、同じパッケージにあるクラス/メソッドによってフィールドを変更できるようにすることは、カプセル化の原則に反しています。コードをリファクタリングして、クラスを別のパッケージに移動したいとします。それはコードを壊すでしょう！
これらの可視性は両方とも、過去の時代遅れで準備が不十分な機能であると考えています。最近それらを使用し、同時にスパゲッティブロブを防ぐ理由はありますか?
パッケージの可視性は、パブリック アクセスよりも制限されたアクセスを提供します。これにより、API の一部をパッケージにのみ公開し、外部に公開することができなくなります。
フィールドの場合、パッケージの可視性をデフォルトにすると、カプセル化されていないデータがデフォルトになります。ただし、メソッドの場合、パッケージの可視性をデフォルトにすることで、初心者が Java を使いやすくなります。両方に 1 つのルールを使用すると、言語の複雑さが軽減されます。
驚いたことに、誰も TDD について言及package-privateしていませんprotected。
TDD は、Java が作成された後に「発明」されたようですが、クラスをテストするという考えは明らかに、本格的な TDD よりも前のものです。Java の設計者が を考案したのpackage-privateは、正確にはテスト目的だったのでしょうか?
すべてのTDD担当者が知っているように、テストクラスのパッケージ指定がテスト対象のアプリクラスのパッケージ指定と一致する限り、テストクラスを同じ実際のディレクトリに含める必要さえないため、現在の配置はかなりエレガントです。この構造には 2 つのメリットがあります。1) アプリ コードとテスト コードを混同する必要がない、2) テスト コードを好きなように構造化できる (たとえば、単体テスト、機能テスト、エンドツー テスト用に別のディレクトリ構造を作成するなど)。 -テスト終了など