パブリックAPIを内部実装から分離するための最良の方法

Question

私は（Scalaで）小さなフレームワークを開発していて、フレームワークのユーザーのためにクリーンでシンプルなインターフェースを定義したいと思っています。これらのインターフェースの一部はフレームワーク自体で実装する必要がありますが、フレームワークの「表面」を小さくシンプルに保つために、これらの実装をユーザーから隠したいと思います。

私の考えは、これらすべての内部的なものが入るフレームワークのルートパッケージ内に「内部」パッケージを置くことです。

com/
  example/
    framework/
      internal/
        SomeImplementation.scala
        SomeInternalThing.scala
      SomethingPublic.scala
      SomeInterface.scala

もう1つの一般的なオプションは、公開用の「api」パッケージを作成することですが、通常のユーザーにとっては、パッケージパスをできるだけ短くする必要があると思います。

com/
  example/
    framework/
      api/
        SomethingPublic.scala
        SomeInterface.scala
      SomeImplementation.scala
      SomeInternalThing.scala

もう1つのより根本的な方法は、2つの別個のプロジェクトを作成することです。1つはパブリックAPI用、もう1つは実装用です。これは基本的にJava EEの世界で行われていることです。しかし、私は公式の標準を作成していないので、これは5月のシナリオでは少しやり過ぎかもしれません。

何を好みますか、そしてその理由は何ですか？他に何か提案はありますか？

Answer 1

私は間違いなく「やり過ぎ」の解決策を採用します。API用の公開プロジェクトと実装用の別のプロジェクトがあります。

com/
  example/
    framework/
      api/
      implementation/

もちろん、実装はapiに依存します。 2つの利点があります。

1. パブリックAPIインターフェイスをクリーンに保つことは簡単です。 ideが「public」キーワードを追加したため、APIに忍び寄るクラスはありません。

2. ベストプラクティスに従うと、常に長期的に見れば配当が支払われることがわかりました。したがって、公式の標準を作成していない場合でも、このプラクティスに従うことで、フレームワークがコードとユーザーベースで拡大する場合に問題が発生しないことを確認できます。