1

パブリック インターフェイスを独自のパッケージに入れてもよろしいでしょうか (私の組織のみ)。

例えば

com.example.myprogram - contains all normal code

com.example.myprogram.public - contains public accessible interfaces

com.example.myprogram.abstract - contains abstract classes

これは良いことなのか悪いことなのか、デメリットはありますか？

4

4 に答える 4

3

私はこの慣習がまったく好きではありません。抽象クラスと具象クラスの両方のクラスと、機能に応じたインターフェイスをグループ化する必要があります。

例として Java API を見てください。Sun は Collections インターフェースを実装から分離しましたか? いいえ。Sun のプラクティスが常に最良のガイドとは限りませんが、この場合は同意します。

やらないでください。

于 2010-03-06T16:55:15.403 に答える
2

2 つの一般的な方法を提案できます。

  1. インターフェイスが将来さらに多くの実装を持つ可能性があると本当に考えている場合 (つまり、API に取り組んでいる場合)、それらを別のモジュールに移動して、たとえば「core」という名前の特別なパッケージを作成します。( com.example.myprogram.core)。実装は、対応するパッケージ ( などcom.example.myprogram.firstimpl) に含まれている必要があります。

  2. 実装が1つしかない場合は、すべてのインターフェースをcom.example.myprogramパッケージに入れ、すべての具象クラスをin com.example.myprogram.implパッケージに入れます。

于 2010-03-06T16:03:41.983 に答える
0

それが悪い習慣だとは思えませんが、構文定義ではなく論理機能ごとに整理することを検討したいかもしれません。これにより、機能インターフェース/抽象クラス/通常コードの特定のユニットのすべてのコードが同じパッケージ。これは、モジュラー プログラミングの原則の 1 つです。

そうは言っても、プロジェクトのサイズによっては、すべてのインターフェイス (ただし、それらのみ) を個別のパッケージに入れることが必要になる場合があり、純粋なコンポーネント ベースのプラグイン アーキテクチャを使用している場合は、ほとんど必要になる可能性があります (他のモジュールがそれについてのみ知るようにするため)。インターフェイスと実際の実装は何らかの方法で動的に注入されます)。

于 2010-03-06T16:02:11.510 に答える
0

パブリック インターフェイスは、システム モジュールまたはシステム間の正式な契約です。そのため、それらをコードの残りの部分から分離して目立たせることは理にかなっています。

たとえば、私が取り組んだシステムでは、システムのサーバー コンポーネントとクライアント コンポーネントの間のすべてのパブリック インターフェイスが、特別なシステム モジュール (当然のことながら "api" と呼ばれます) に配置されています。これには多くの望ましい効果があります。その中には次のものがあります: - 意味的に、通信がどのように行われるかについて何らかの情報が必要な場合にどこを見ればよいかがわかります - API モジュールを個別にバージョン管理できるため、そうでないときに特に役立ちます。移動するターゲットが必要です。つまり、他の誰かがインターフェイスを変更して自分の側に適応するように要求している間、絶えずキャッチをプレイするのではなく、「API v.1.1」をサポートするアプリケーションを提供する契約に署名します。

それは、それらが何のためにあるのかを区別するためにサブパッケージでさらに整理すべきではないという意味ではありません。:)

要約すると、コード ベースの残りの部分からインターフェイスを分離することは正しいことですが、特定のニーズによっては、さらに一歩進んで別のシステム モジュールにインターフェイスを分離することをお勧めします。

于 2010-03-06T16:03:35.423 に答える