3

システムが依存するインターフェイスを定義しました。

IMethodCall

を実装する一連のクラスを作成しましたIMethodCall。

AbstractMethodCall
ConstructorCall
TargetConstructorCall
VoidMethodCall
TargetVoidMethodCall
NonVoidMethodCall
TargetNonVoidMethodCall

それらは実装の詳細であり、私のシステムはそれらについて知りません (少なくとも、知る必要はありません)。

その時点で手元にある一連のデータに基づいて、インスタンス化する実装を選択する背後にはいくつかのトリッキーなロジックがあるため、すべてのロジックを 1 つの場所にグループ化するファクトリを作成することにしました。

MethodCallFactory

ここで使用されるパッケージ構造がどうあるべきかを理解しようとしています。私の最初のアイデアは、すべての具体的なクラスをmethodCallsパッケージに入れ、それらをパッケージ保護として設定することでした。次に、システムのユーザーがそれらを使用できるように、外にIMethodCall出しました。MethodCallFactory問題は、具象クラスをパッケージ保護として配置すると、ファクトリもパッケージに含まれている必要があることです。これは、外部ビューアーの場合、それを含むためだけに存在するパッケージのように見えるため、ちょっと奇妙に思えます。工房。

現時点で最善のトレードオフは、具体的なクラスを公開することですが、この種の状況を通常どのように処理するのだろうか?

4

2 に答える 2

2

このような状況に直面した場合、具体的な実装クラスとファクトリを同じパッケージに入れ、実装クラスのパッケージを非公開にします。

あなたは、このアプローチは外部からの視点のせいで奇妙に思えるとおっしゃいました。外部のユーザーが実装クラスがあることを知らないことに私は同意しません。ほとんどの IDE は、アクセスできない場合でも、パッケージ内のクラスを表示します。また、プログラマーが実装クラスを使用しようとすると、コンパイラーはアクセスを禁止しながらクラスが存在することを暗示します。

また、パッケージにファクトリのみが含まれていて、それが非公開の実装であるというのは奇妙だという意見にも同意しません。このクラスのグループは密接に関連しているため、それらを 1 つの場所にグループ化することは論理的です。

于 2012-05-13T15:47:07.593 に答える
0

ファクトリ クラスとインターフェイスをパブリック パッケージに配置し、実装されたクラスを内部パッケージに配置できます。

内部パッケージは推奨されません。内部パッケージのクラスはいつでも変更される可能性があります。ユーザーは、パブリック パッケージで API を呼び出す必要があります。

例えば：

公開パッケージは org.feeling.ui.dialogs です

内部パッケージは org.feeling.internal.ui.dailogs です

于 2012-05-13T15:28:18.817 に答える