Javaで書かれたAPIで内部クラスをカプセル化する方法は？

ライブラリを書かなければならない。当然、非常に小さなAPI（必要に応じてできるだけ広い）のみを使用する必要があります。ライブラリの内部はやや複雑です。したがって、構造化が必要です。

構造化について、私は現在2つの方法を考えています。

1.パッケージを使用します。

長所：ライブラリはきちんと構成できます。その場所のすべて。

短所：パッケージの境界線を介したクラスの使用にはパブリッククラスが必要であり、したがってライブラリ全体のAPIを拡張します。

2.すべて1つのパッケージで静的内部クラスを使用します。

長所：必要なパブリッククラス（クラス、メソッドなど）はごくわずかです。

短所：クラスは、それらを構造化するためにのみ非表示になります。これは、非常に多くの静的内部クラスが使用される非常に数少ないユースケースの1つです。開発者はそれに慣れておらず、見落とす可能性があります。

よく構造化されたライブラリで小さなAPIを実現するより良い方法はありますか？

編集：言及するのを忘れていました：Androidライブラリ用です。したがって、java9はありません。

私はあなたが何をしているのかを理解しています。クラスをパッケージとして、パッケージをモジュールとして使用しているため、パッケージ内で自分自身を分離しながら、クラスを使用してパッケージ内で整理できます。

それはとても賢いです。賢いことに注意してください。

これにより、同じソースファイル内の複数のクラスを妨害するように強制され（好まれるかもしれません）、パスには余分な大文字の単語が含まれます。

また、リフレクションを使用して外部から侵入する場合を除いて、パッケージ内にテストコードを作成する必要があります。

それ以外の場合、これは機能します。変に見えるだけです。

人々は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パッケージを作成し、それらのパッケージを実装依存であり、警告や下位互換性なしに変更される可能性があることを文書化することにより、慣例としてそれを行うことができます。