Javaパッケージレベルのスコープは役に立ちますか？

私はパッケージスコープの考え方を理解しています。しかし、真剣に使用しようとするたびに、それが役立つと思っていたニーズに合わないことに気づきました。

私の主な問題は常に、私がスコープを制限したいものは決して同じパッケージに入っていないということです。それらは概念的にはすべてリンクされている可能性がありますが、アプリケーション内のデータの論理的な分割では、それらをより大きなパッケージの個別の子パッケージとして扱います。

たとえば、Missionモデルを使用していて、mymissionServicesなどの他のMissionツールのみにいくつかのメソッドを使用させたい場合があります。ただし、最終的にはパッケージとしてMissions.modelsとMissions.servicesが使用されるため、MissionModelとMissionServiceは同じパッケージスコープではありません。昇格されたアクセス許可が必要なものが、パッケージに適切に含まれているにもかかわらず、それらのアクセス許可が不要な多くのものが含まれていないような状況は決してありません。また、メソッドをスコープするパッケージの利点が、すべてを同じパッケージに配置するようにプロジェクトアーキテクチャを変更することを正当化することはほとんどありません。多くの場合、アスペクトまたは何らかの制御の逆転のどちらかが、パッケージのスコープを簡単に検討した問題に対するより優れたアプローチであることが判明します。

私は好奇心が強いのですが、これは一般的にすべてのJava開発者に当てはまると考えられているか、私が行っている作業のほんの一部にすぎません。パッケージスコープは現実世界で多く利用されていますか？それが使用するのに適した形態と考えられる多くのケースがありますか、それとも現代の開発でめったに利用されないレガシーな振る舞いと見なされていますか？

パッケージのプライベートスコープがデフォルトである理由については何も尋ねていません。デフォルトに関係なくいつ使用する必要があるかを尋ねています。なぜそれがデフォルトであるかについてのほとんどの議論は、パッケージスコープが実際に役立つ場合には実際には入りません。代わりに、一般的に使用される他の2つのスコープがデフォルトではないはずであるという理由だけを主張して、除去プロセスによってパッケージが勝つようにします。また、現在の開発状況についてお伺いします。具体的には、他のツールやパラダイムによってパッケージのスコープの有用性が低下するところまで開発したので、それをデフォルトにするという決定が理にかなっていたときのことです。

java.util.*パッケージ全体で、パッケージレベルの保護を使用してコードが記述される場合があります。例えば、このビットjava.util.String- ジャワ6コンストラクタ：

// Package private constructor which shares value array for speed.
String(int offset, int count, char value[]) {
    this.value = value;
    this.offset = offset;
    this.count = count;
}

またはこのgetCharsメソッド：

/** Copy characters from this string into dst starting at dstBegin. 
    This method doesn't perform any range checking. */
void getChars(char dst[], int dstBegin) {
    System.arraycopy(value, offset, dst, dstBegin, count);
}

この理由は、コードの設計者（およびjava.util.*かなり大きなライブラリと考えることができます）は、さまざまな安全性（配列の範囲チェック、他のフィールドへの直接アクセス）の損失を犠牲にしてより高速なパフォーマンスを実現する機能を望んでいたためですそれは、インターフェースではなく実装を意味します。そうでなければ、パブリックメソッドを介して不変であると見なされるクラスの部分への「安全でない」アクセスです）。

これらのメソッドとフィールドを、java.utilパッケージ内の他のクラスのみがアクセスできるように制限することにより、これらのメソッドとフィールド間の密接な結合が可能になりますが、これらの実装の詳細が公開されることもありません。

アプリケーションで作業していて、他のユーザーについて心配する必要がない場合、パッケージレベルの保護は心配する必要はありません。デザインの純粋さのさまざまな側面を除いて、あなたはすべてpublicを作り、それで大丈夫かもしれません。

ただし、他のユーザーが使用するライブラリで作業している場合（または、後でリファクタリングするためにクラスが複雑になりすぎないようにしたい場合）、必要に応じて提供されている最も厳しいレベルの保護を使用する必要があります。多くの場合、これはを意味しprivateます。ただし、場合によっては、同じパッケージ内の他のクラスに実装の詳細を少し公開して、繰り返しを避けたり、2つのクラスとその実装の結合を犠牲にして実際の実装を少し簡単にする必要があります。したがって、パッケージレベルの保護。

プライベートまたは保護されたメソッドの可視性をパッケージにエスカレートして、junit-testが外部からアクセスしてはならない実装の詳細にアクセスできるようにすることがあります。

junit-testはテスト対象のアイテムと同じパッケージを持っているので、これらの実装の詳細にアクセスできます

例

  public class MyClass {
    public MyClass() {
        this(new MyDependency());
    }

    /* package level to allow junit-tests to insert mock/fake implementations */ 
    MyClass(IDependency someDepenency) {...}
  }

これが「良い」使用法かどうかは議論の余地がありますが、実用的です

それがサブパッケージであるかのようにパッケージのドット名を使用する傾向がある世界では、特にデフォルトとして、それはそれほど有用ではありません。Javaにはサブパッケージなどがないため、xyinternalsは、abにアクセスする場合よりもxyにアクセスできます。パッケージ名は同じでも異なっていても、部分一致は共通点がないことと変わりません。

元の開発者はその規則が使用されることを決して期待しておらず、Adaスタイルの階層型パッケージの複雑さを追加せずに物事をシンプルにしたかったと思います。

Java 9はこれにある程度対処しているため、モジュールに複数のパッケージを配置して、一部のみをエクスポートできます。ただし、これにより、パッケージのスコープがさらに冗長になります。

理想的な世界では、デフォルトのスコープを「包含モジュールが存在する場合はモジュールスコープに、それ以外の場合はパッケージスコープ」に変更します。その後、それを使用してモジュール内の実装を共有し、エクスポートされたインターフェースを壊すことなくリファクタリングを行うことができます。しかし、下位互換性を損なう、または他の理由で悪いことになる微妙な点があるかもしれません。

説明する結束のタイプは、実際にパッケージアクセスを使用する最良の例ではありません。パッケージは、インターフェース上で交換可能なコンポーネント、モジュールを作成するのに便利です。

これは大まかなシナリオの例です。コードが、機能の凝集とコンポーネント化に重点を置いて再編成されたとします。おそらく次のような3つのjarファイル：

**MissionManager.jar** - an application which uses the Java Service Provider Interface to load some implementation of missions, possible provided by a 3rd party vendor.

**missions-api.jar** - All interfaces, for services and model
    com...missions
        MissionBuilder.java   - has a createMission method
        Mission.java - interface for a mission domain object
    com...missions.strategy
        ... interfaces that attach strategies to missions ...
    com...missions.reports
        .... interfaces todo with mission reports ....

   **MCo-missionizer-5000.jar** -  provides MCo's Missionizer 5000 brand mission implementation.
       com...missions.mco
                  Mission5000.java - implements the Mission interface.
       com...missions.strategy.mco
              ... strategy stuff etc ...

Mission5000.javaでパッケージレベルを使用することで、他のパッケージやMissionManagerなどのコンポーネントがミッションの実装に密結合できないことを確認できます。これは、「M co」の「サードパーティ」提供コンポーネントのみが実際に独自のブランドのミッションの実装を作成するものです。Mission ManagerはMissionBuiler.createMission（...）を呼び出し、定義されたインターフェースを使用する必要があります。

このように、Mission実装コンポーネントが置き換えられた場合、MissionManager.jarのインプリメンターがAPIをバイパスせずにMCoの実装を直接使用したことがわかります。

したがって、MCo-missionizer5000.jarを競合製品と交換できます。（または、ミッションマネージャーのユニットテスト用のモック）

逆に、MCoは独自の宣教師の企業秘密をある程度隠すことができます。

（これは、コンポーネントの不安定性と抽象化のアイデアの適用にも関連しています。）

Javaのパッケージスコープは階層的な方法で設計されていないため、ほとんど役に立ちません。パッケージスコープはまったく使用せず、すべてのクラスをパブリックとして定義します。

代わりに、パッケージ階層と事前定義されたパッケージ名に基づく独自のアクセスルールを使用します。

「CODERU-Rules」の詳細グーグルに興味があるなら。