Javaで書かれたAPIで内部クラスをカプセル化する方法は？
ライブラリを書かなければならない。当然、非常に小さなAPI（必要に応じてできるだけ広い）のみを使用する必要があります。ライブラリの内部はやや複雑です。したがって、構造化が必要です。
構造化については、現在2つの方法があります。
1。パッケージを使用します。
pros：ライブラリはきちんと構成できます。その場所のすべて。
cons：パッケージボーダーを介したクラスの使用にはパブリッククラスが必要であり、ライブラリ全体のAPIを拡張します。
2。すべて1つのパッケージで静的内部クラスを使用します。
pros：必要なパブリックアイテム（クラス、メソッドなど）はごくわずかです。
cons：クラスは、それらを構造化するためにのみ非表示になります。これは、非常に多くの静的内部クラスが使用される非常に数少ない使用例の1つです。開発者はそれに慣れておらず、見落としているかもしれません。
適切に構造化されたライブラリで小さなAPIを実現するより良い方法はありますか？
編集：言及するのを忘れていました：Androidライブラリ用です。したがって、Java9はありません。
私はあなたが何をしているのかを理解しています。クラスをパッケージとして使用し、パッケージをモジュールとして使用しているため、パッケージ内で自分自身を分離しながら、クラスを使用してパッケージ内で整理できます。
それはとても賢いです。賢いことに注意してください。
これにより、同じソースファイル内の複数のクラスを妨害することになります（好むかもしれません）。パスには余分な大文字のWordが含まれます。
また、リフレクションを使用して外部から侵入する場合を除いて、パッケージ内にテストコードを作成する必要があります。
それ以外の場合、これは機能します。変に見えるだけです。
人々は、Hashtableで EntrySet のように使用される内部クラスにより慣れています。プライベートなので作成できませんが、パブリックインターフェースを実装しているので、インターフェースを介して話しかけるだけで、何かを手に入れられます。
しかし、インターフェースを介しても私に話してほしくないクラスを説明している。だから私にはインターフェースがありません。これは、私が見るものや混乱するものがないことを意味します（ソースを提供しない限り）。
私が予測する最大の問題は、APIを維持するこの混乱している初心者です。あなたは彼らにドキュメンテーションとコメントを投げることができますが、彼らがどちらも読んだり信頼したりしないときは特大になりません。
言語の不足を補うさらに別のパターンを作成しました。 Javaには、パッケージのグループへのアクセスを許可するアクセス修飾子がありません。「モジュール」アクセス修飾子が提案されたと聞きましたが、その兆候は見られません。
デフォルトのアクセス修飾子（修飾子なし）は、継承を通じてこっそり侵入しても構わない場合を除いて、ここで使用する可能性が高く、その場合は保護されます。
Modifier Class Package Subclass World
public Y Y Y Y
protected Y Y Y N
no modifier Y Y N N
private Y N N N
あなたが本当に欲しいのはモジュールへのアクセスです。そうすれば、テストを1つのパッケージにまとめ、コードを別のパッケージにまとめることができます。残念ながら、Javaにはありません。
ほとんどの人は1を実行してAPIを拡張します。インターフェイスを適切に使用することで、実装からのプレッシャーがなくなります。
必要なものを1にハッキングすることは、さらに醜いことです。コールスタックをのぞいて、呼び出し元が気に入らないパッケージからのものである場合は常に例外をスローします。ああ。
必ず、コードをパッケージに分けてください。保守性の向上に大きく貢献します。
エンドユーザーがアクセスしてはいけないものにアクセスできないようにするには、APIをインターフェースと実装に分離する必要があります。
Javaインターフェースの観点からAPI全体を定義し、実装オブジェクトを生成するためにいくつかのファクトリークラスを提供することにより、文字通りそれを行うことができます。これがJDBCが行うことです。
または、internalパッケージを作成し、それらのパッケージを実装依存であり、警告や下位互換性なしに変更される可能性があることを文書化することにより、慣例としてそれを行うことができます。