4

A、B、C が AbstractBaseClass から派生し、それらがすべて同じ Java プロジェクトの一部であると仮定すると、フォームのパッケージ構造は...

 package com.whatever.###
 AbstractBaseClass.java

 package com.whatever.###.###
 A.java
 B.java
 C.java

...一般に、次の形式のパッケージ構造よりも優先されます...

 package com.whatever.###.###
 AbstractBaseClass.java
 A.java
 B.java
 C.java

?

...または、気にする人はほとんどいませんか?

4

5 に答える 5

1

最初の例を使用してかなり複雑なアプリケーション アプリケーションを作成しました。ここでは、設計を正当化する方法を示します。私の場合、引受ケースの価格設定に関連する共通のインターフェースがありましたが、実際のデータを入力するさまざまな Web サービスを提供できる複数のベンダーがありました。これがパッケージ構造でした

com.example.pricing
 \IPricingProvider.java
 \AbstractPriceProvider.java
com.example.pricing.vendorA
   \PricingEngine.java
com.example.pricing.vendorB
   \PricingEngine.java
com.example.pricing.vendorC
   \PricingEngine.java

次に、コードで を使用してimport、必要なエンジンを配線しました。このような：

import com.example.pricing.*;
import com.example.pricing.vendorB.*;

IPricingProvider provider = Engine.create();

私にとっての利点は、ベンダーごとに複雑で乱雑な実装を行うことができ (2 つはレスト ベースで、1 つは Web サービスを使用しwsimportていたため、生成された Java ファイルが多数ありました)、Eclipse のオートコンプリートが完全な悪夢のように見えないようにすることができました。また、単一のベンダーを別の開発者に引き渡すことも容易になりました。

于 2013-02-07T18:15:09.143 に答える
0

それは実際には一般的に良い習慣です。パッケージが多すぎると、すぐに混乱する可能性があります。実装クラスを同じパッケージに保持することで、余分な import ステートメントを避けることができ、アプリケーション コードベースの拡大に合わせて抽象クラスを簡単に見つけることができます。これに対する例外は、すべてが抽象クラスから拡張された実装クラスの大きなグループがある場合です。たとえば、MySQL 実装と多数の抽象クラスの Mongo 実装がある場合、それらを別々のサブパッケージに入れたいと思うかもしれません。何かのようなもの

com.foo.data  <--- abstract classes
com.foo.data.mysql  <-- impl
com.foo.data.mongo  <-- impl
于 2013-02-07T18:20:28.903 に答える
0

意外にも答えは。場合によります。

2 つの兄弟の子孫を作成する場合は、それぞれに 1 つのファイル (3 つの場合のように) が適しています。それらが小さい場合、および/またはほとんど常に両方を使用する場合 (たとえば、ディレクトリとファイル)、とにかくそれらをすべて 1 つに保持するための実用的な議論があります。

最後の子孫のみが使用可能な機能を持つ深い継承階層を構築している場合 (クラスが抽象的であるほど、機能は少なくなります)、別のファイルに配置しても意味がありません。

于 2013-02-07T18:24:52.863 に答える
0

パッケージ構造は、相反する 2 つの目的を果たします。

  1. API とコードを学習している人が、自分のやりたいことを行うクラスを簡単に見つけられるようにします。この場合、似たようなものをグループ化し、Javadoc をブラウズする人がどこを見ればよいかを明確にするパッケージ名を使用する必要があります。これは、API クライアントにとって意味のある幅広い区分を持つ少数のパッケージを支持するものです。
  2. クラスが互いのパッケージ プライベート API にアクセスできるようにします。これは、密接に結合されたクラスの多くの小さなグループを主張しています。

パッケージのような大規模な組織は、現在の実装の詳細に依存するべきではないため、(2) よりも (1) を優先します。

深い階層は習得が難しいため、 name 要素を追加しても API の習得が容易にならず、現在のタスクに関係のないビットを除外するのに役立たない場合は、省略してください。

于 2013-02-07T18:20:51.327 に答える
0

それは、クライアントにとってどちらの部分がより重要かによると思います: スーパークラスまたはサブクラス?

後者は、最初にサブクラスを考え、いくつかの共通部分をスーパークラスにリファクタリングしただけの場合によくあります。次に、Louis がコメントで述べたように、このスーパークラスは同じパッケージ内にあり、公開されないようにする必要があります。クライアントがサブクラスの型を確認する必要がある場合は、このパターンになる傾向があります。

ただし、実装から抽象化し、クライアントが通常ジェイソンの回答のようにスーパークラスでのみ動作する場合は、各サブクラスを独自のパッケージに入れる戦略に従う必要があります。多くの場合、これらのサブクラスは、外部コードとは関係のない追加のクラスを必要とするため、独自のパッケージを用意することをお勧めします。

于 2013-02-07T18:22:12.603 に答える