背景: 多くのプロジェクトでは、内部コードのほとんどすべてのクラスが public であり、必要がない場合でも final ではないことに気付きました。ただし、この決定をデフォルトで行うのではなく、実際にシステムの他の部分から使用することを意図している場合にのみ、クラスをパブリックにすることが賢明だと思われます。パッケージで保護されたクラスを持つことは、モジュール間の境界を強制するための簡単なメカニズムであり、クラスの使用目的に関するドキュメントとして機能します。
プログラムを壊さずに保護できるすべてのクラスを保護し、サブクラスを持たないすべてを最終的なものにする (できれば無料の :-) ツールがあれば、保護メカニズムを意識的に使用するための良い出発点になるでしょう。(もちろん後で微調整する必要があります。) そのようなツールを知っていますか?
警告: OSGI や計画中のスーパーパッケージなど、より優れたモジュール化メカニズムがあることは承知しています。しかし、現在の多くのプロジェクトでは、これはオプションではなく、単純な古い Java メカニズムを使用することは簡単にできることです。また、これは、コードの所有権を共有している (必要に応じて誰もがパブリックに戻すことができる) 場合にのみ機能し、他のユーザーが使用するライブラリではなく、最終製品を開発している場合にのみ機能します。また、物事を最終的なものにすることの利点についてもよくわかりません-これにより、AOPとモックが防止されます。
明確化：私が言ったように、私はフェンスを越えて変更できない人に投げ出されたライブラリについて話しているのではなく、必要に応じてすべてを変更およびリファクタリングすることが奨励されている中規模プロジェクトの内部コードについて話している. package protected または final について話しているときは、「誰かがそれらの制限を解除する必要があると感じるまで保護されている」と考えてください。ツールによって設定された制限を解除する必要があると感じた場合は、それを歓迎します。