Javaプログラミングにおけるパッケージパッケージパッケージの内容とパッケージオブジェクトの仕様を詳しく理解する
5732 ワード
パッケージのコンテンツパッケージの内容は、機能に関連するクラスとインタフェースのみを含むように注意深く設計する必要があります.パッケージ内のクラスは、パッケージ内の他のクラスの非プライベートメンバーに自由にアクセスできます.一部のクラスでは、他のクラスの内部詳細にアクセスするのに十分な権限がある場合もあります.このようなクラスがクラスメンバーを誤操作しないように、クラスメンバーを保護する必要があります.privateとして宣言されていないメンバーは、同じパッケージ内の他のすべてのタイプにアクセスできるため、関連のないクラス間のレンコンの度合いは、私たちが望んでいるよりも高くなる可能性があります.
パッケージはまた、有用なインタフェースとクラスを探すプログラマーに論理パケットの機能を提供します.関連しないクラスからなるパケットは、プログラマーがどのインタフェースとクラスが役に立つかを見分けるのが難しいが、クラスの論理パケットはプログラマーがコードを再利用するのに役立つ.プログラマーは論理パケットを通じて必要なものをより簡単に見つけることができるからだ.パッケージに関連する緊密なレンコンのタイプセットのみが含まれている場合は、名前の競合を回避するために、タイプにより直感的な名前を付けることができます.
パッケージはネストできます.例えばjava.langはネストされたパケットであり、パケットLangはより大きなパケットjavaにネストされ、パケットj avaは他のパケットも含まれている.ネストにより、関連するパケットが階層を有するネーミングシステムを構成します.
例えば、ニューラルネットワークや遺伝アルゴリズムのような適応システムのようなパケットのセットを作成するために、パケットを円点で区切った名前で命名し、ネストされたパケットを作成することができます.
上記の宣言文を含むソースファイルはadaptiveにあります.neuralNetパッケージ、adaptive.neuralNetパッケージ自体はadaptiveパッケージのサブパッケージです.adaptiveパッケージには、汎用的な適応アルゴリズムに関連するクラス、例えば汎化問題記述クラスまたはベンチマークテストクラスが含まれる場合がある.階層内でより深い位置にあるパケット(adaptive.neu-ralNetまたはadaptive.geneticなど)には、特定のタイプの適応アルゴリズムに関連するクラスが含まれます.
パッケージのネストは、関連するパッケージを組織するツールにすぎず、パッケージ間の特別なアクセス権を提供することはできません.
adaptive.geneticパッケージのクラスコードはadaptiveまたはadaptiveにアクセスできません.neuralNetパッケージにパッケージアクセス権を持つメンバーで、パッケージの役割ドメインは特定のパッケージにのみ適用されます.パケットのネストは、関連するパケットをグループ化し、プログラマが論理階層で目的のクラスを見つけやすくするのに役立ちますが、それ以外のメリットはありません.
パッケージの注記
パッケージには注釈もあります.しかし、問題は、パッケージは組織構造であり、ソース・コード・エンティティがなく、実際の定義がないため、クラスやメソッドのように注釈することはできません.したがって、パッケージの注釈は、ソース・ファイルでパッケージの宣言文を注釈することによってのみ実現できます.ただし、各パケットには、その注釈を持つことができると宣言するパケットは1つしかありません.
では、いったいどのようにバッグに注釈をつけるのでしょうか.実際、Java言語では、プログラマが「単一注釈のパッケージ文」ルールを何らかの方法で処理する必要はありません.提案する方法は、パッケージディレクトリにpackageというi nfoを作成することである.JAvaのファイルで、このファイルにはパッケージ文とそのパッケージの注釈のみが格納され、他の内容は配置されません.例えば、attrパッケージ用のパッケージ1 info.JAvaファイルは次のように見えます.
ここでPackagespec、Developmentsite、Developmentmodelは注釈タイプを修飾するために使用されます.もちろん、実行時の保存ポリシーがあります.义齿JAvaファイルは、パッケージ内の他のソースファイルと一緒にコンパイルする必要があります.
パッケージに関するすべての情報をパッケージに配置することをお勧めします.JAvaファイルにあります.そうすると、ファイルの先頭にドキュメントコメントを配置して、パッケージドキュメントにコメントすることができます.
パッケージ・オブジェクトおよび仕様パッケージは、通常、ある仕様を実装し、通常は組織から来ます.Packageオブジェクトは、他の反射タイプとは異なり、パッケージの作成や操作に使用することはできません.パッケージが実装する仕様に関する情報(仕様のタイトル、ベンダー、バージョン番号)と、パッケージの実装自体に関する情報(パッケージのタイトル、ベンダー、バージョン番号)を提供するために、情報を提供する知識ベースとしてのみ使用できます.パッケージは通常、単一の組織から作成されますが、統計分析ライブラリなどの仕様は、他の組織で定義されている可能性があります.パッケージを使用するプログラムは、パッケージが実装する仕様のバージョンを知る必要がある場合があります.これにより、あるバージョンでのみ定義された機能を使用できます.同様に、これらのプログラムは、主に異なるバージョンで存在する可能性のある欠陥を処理するために提供される実装バージョンを知る必要があるかもしれない.Packageクラスの主な方法では、次の情報にアクセスできます.・public Stri ng getName():パッケージの名前を返します. .public string getspecificationTitle p:パッケージで実装されている仕様のタイトルを返し、タイトルが不明な場合null, を返します. .public string getspecificationversion():パケットが実装する仕様のバージョン情報を記述する文字列を返し、バージョン情報が不明な場合null、 を返します. .public string getspecificationvendor Q:パッケージで実装された仕様を所有し維持する仕入先の名前を返します.仕入先が不明な場合はnull、 を返します. .public string getImplerentationTitle():パケットが提供するインプリメンテーションのタイトルを返し、タイトルが不明な場合nullを返します.・public string getImplementationversion():パケットが提供するインプリメンテーションのバージョン情報を記述する文字列を返し、バージョン情報が不明な場合nullを返します. ・public string getImplementationvendor():インプリメンテーションを提供する組織(ベンダー)の名前を返します.組織が不明な場合はnull、 を返します.
例えば、私たちのシステムでjavaを抽出します.langパッケージのこれらの情報は、次の結果を得ます.'
スペシフィケーション・バージョン番号は、句点区切りで区切られた非負の数値で構成されています.例えば‘‘‘2.0’’‘または’11.0.12「このモードでは、iscompatiblewithメソッドを呼び出して、このモードに従うバージョン番号とパッケージのバージョン番号を比較できます.パッケージのバージョン番号が送信者のバージョン番号以上である場合、メソッドはtrueを返します.この比較は、送信されたバージョン番号の対応する位置より小さい場合、毎回1つのピリオドで区切られた数字のみを比較します.の値を指定すると、この2つのバージョンは互換性がありません.いずれかのバージョン番号が他のバージョン番号より長い場合、短いバージョン番号に欠けている部分はゼロとみなされます.たとえば、パッケージの仕様バージョン番号が「1.4」であり、iscompatiblewithメソッドで「1.2」、「1.3.1'.または「.1.181.と比較するとtrueが返されますが、「1.4.2'.または」.5と比較するとfalseが返されます.このような結論は,この比較メカニズムが仕様バージョンが後方互換性があると仮定しているためである.
インプリメンテーションのバージョン番号には、インプリメンテーションを提供する異なる組織がインプリメンテーションのバージョンを異なる定義を行うため、フォーマットが規定されていません.インプリメンテーション・バージョン間で唯一できる比較は、バージョンが同じかどうかをテストすることであり、下位互換性の仮定はありません.
パッケージは密封することができます.これは、このパッケージにクラスを追加できないことを意味します.カプセル化されていないパケットは、クラス検索パス内の複数の異なる場所からのクラスを含むことができ、カプセル化されたパケットの内容は、特定のアーカイブファイルまたはURLによって指定された場所から同じ場所から来なければならない.パッケージが密封されているかどうかを判断するには、2つの方法があります.
.public boolean issealed p:パッケージが密封されている場合はtrueoに戻ります
.public boolean issealed(URL url):パケットが所与のURLに対して密封されている場合、trueが返されます.すなわち、パケット内のクラスは、所与のURLからロードできます.パケット内のクラスが所与のURLからロードできない場合、またはパケットがシールされていない場合、falseに戻り、パケットの仕様および実装情報は、通常、パケットとともに格納されたインベントリファイルの一部として提供される.例えば、Javaアーカイブファイル(jar)のインベントリファイルの一部として、25.9.2節「アーカイブファイルjava.util.jar」で説明したように、Javaアーカイブファイル(jar)のインベントリファイルの一部として提供される.パッケージ内のクラスをロードすると、これらの情報は読み出されます.クラスローダ(ClassLoader)は、ロードするクラスのPackageオブジェクトを動的に定義します.
特定のクラスのClassオブジェクトのgetPackageメソッドを呼び出して、このクラスのPackageオブジェクトを得ることができます.指定されたパッケージ名で静的側Packageを呼び出すこともできます.getPackageは、Packageオブジェクトを取得するか、静的側Packageを呼び出す.getPackagesは、クラスローダで現在知られているすべてのパケットからなるPackage配列を返します.この2つのメソッドは、クラス・ローダのget-PackageメソッドまたはgetPackagesメソッドが呼び出されるため、コードを呼び出すクラス・ローダに関連しています.これらのクラス・ローダのメソッドは、特定のクラス・ローダとそのすべての親ローダを検索します.現在のクラス・ローダに設定がない場合は、システム・クラス・ローダが使用されます.パケットが不明な場合、クラス・ローダ・メソッドはnullを返します.パケットのタイプがロードされていないためです.
パッケージはまた、有用なインタフェースとクラスを探すプログラマーに論理パケットの機能を提供します.関連しないクラスからなるパケットは、プログラマーがどのインタフェースとクラスが役に立つかを見分けるのが難しいが、クラスの論理パケットはプログラマーがコードを再利用するのに役立つ.プログラマーは論理パケットを通じて必要なものをより簡単に見つけることができるからだ.パッケージに関連する緊密なレンコンのタイプセットのみが含まれている場合は、名前の競合を回避するために、タイプにより直感的な名前を付けることができます.
パッケージはネストできます.例えばjava.langはネストされたパケットであり、パケットLangはより大きなパケットjavaにネストされ、パケットj avaは他のパケットも含まれている.ネストにより、関連するパケットが階層を有するネーミングシステムを構成します.
例えば、ニューラルネットワークや遺伝アルゴリズムのような適応システムのようなパケットのセットを作成するために、パケットを円点で区切った名前で命名し、ネストされたパケットを作成することができます.
package adaptive. neural Net;
上記の宣言文を含むソースファイルはadaptiveにあります.neuralNetパッケージ、adaptive.neuralNetパッケージ自体はadaptiveパッケージのサブパッケージです.adaptiveパッケージには、汎用的な適応アルゴリズムに関連するクラス、例えば汎化問題記述クラスまたはベンチマークテストクラスが含まれる場合がある.階層内でより深い位置にあるパケット(adaptive.neu-ralNetまたはadaptive.geneticなど)には、特定のタイプの適応アルゴリズムに関連するクラスが含まれます.
パッケージのネストは、関連するパッケージを組織するツールにすぎず、パッケージ間の特別なアクセス権を提供することはできません.
adaptive.geneticパッケージのクラスコードはadaptiveまたはadaptiveにアクセスできません.neuralNetパッケージにパッケージアクセス権を持つメンバーで、パッケージの役割ドメインは特定のパッケージにのみ適用されます.パケットのネストは、関連するパケットをグループ化し、プログラマが論理階層で目的のクラスを見つけやすくするのに役立ちますが、それ以外のメリットはありません.
パッケージの注記
パッケージには注釈もあります.しかし、問題は、パッケージは組織構造であり、ソース・コード・エンティティがなく、実際の定義がないため、クラスやメソッドのように注釈することはできません.したがって、パッケージの注釈は、ソース・ファイルでパッケージの宣言文を注釈することによってのみ実現できます.ただし、各パケットには、その注釈を持つことができると宣言するパケットは1つしかありません.
では、いったいどのようにバッグに注釈をつけるのでしょうか.実際、Java言語では、プログラマが「単一注釈のパッケージ文」ルールを何らかの方法で処理する必要はありません.提案する方法は、パッケージディレクトリにpackageというi nfoを作成することである.JAvaのファイルで、このファイルにはパッケージ文とそのパッケージの注釈のみが格納され、他の内容は配置されません.例えば、attrパッケージ用のパッケージ1 info.JAvaファイルは次のように見えます.
@PackageSpec(name ”Attr Project"，version="1.0"
@DevelopmentSite("attr.project.org")
@DevelopmentModel("open source")
package attr;
ここでPackagespec、Developmentsite、Developmentmodelは注釈タイプを修飾するために使用されます.もちろん、実行時の保存ポリシーがあります.义齿JAvaファイルは、パッケージ内の他のソースファイルと一緒にコンパイルする必要があります.
パッケージに関するすべての情報をパッケージに配置することをお勧めします.JAvaファイルにあります.そうすると、ファイルの先頭にドキュメントコメントを配置して、パッケージドキュメントにコメントすることができます.
パッケージ・オブジェクトおよび仕様パッケージは、通常、ある仕様を実装し、通常は組織から来ます.Packageオブジェクトは、他の反射タイプとは異なり、パッケージの作成や操作に使用することはできません.パッケージが実装する仕様に関する情報(仕様のタイトル、ベンダー、バージョン番号)と、パッケージの実装自体に関する情報(パッケージのタイトル、ベンダー、バージョン番号)を提供するために、情報を提供する知識ベースとしてのみ使用できます.パッケージは通常、単一の組織から作成されますが、統計分析ライブラリなどの仕様は、他の組織で定義されている可能性があります.パッケージを使用するプログラムは、パッケージが実装する仕様のバージョンを知る必要がある場合があります.これにより、あるバージョンでのみ定義された機能を使用できます.同様に、これらのプログラムは、主に異なるバージョンで存在する可能性のある欠陥を処理するために提供される実装バージョンを知る必要があるかもしれない.Packageクラスの主な方法では、次の情報にアクセスできます.
例えば、私たちのシステムでjavaを抽出します.langパッケージのこれらの情報は、次の結果を得ます.'
Specification Title: Java Platform API Specification
Specification Version: 1.4
Specification Vendor:Sun Microsystems，Inc.
Implementation Title:Java Runtime Environment
Implementation Version:1.5.0_02
Implementation Vendor: Sun Microsystems，Inc.
スペシフィケーション・バージョン番号は、句点区切りで区切られた非負の数値で構成されています.例えば‘‘‘2.0’’‘または’11.0.12「このモードでは、iscompatiblewithメソッドを呼び出して、このモードに従うバージョン番号とパッケージのバージョン番号を比較できます.パッケージのバージョン番号が送信者のバージョン番号以上である場合、メソッドはtrueを返します.この比較は、送信されたバージョン番号の対応する位置より小さい場合、毎回1つのピリオドで区切られた数字のみを比較します.の値を指定すると、この2つのバージョンは互換性がありません.いずれかのバージョン番号が他のバージョン番号より長い場合、短いバージョン番号に欠けている部分はゼロとみなされます.たとえば、パッケージの仕様バージョン番号が「1.4」であり、iscompatiblewithメソッドで「1.2」、「1.3.1'.または「.1.181.と比較するとtrueが返されますが、「1.4.2'.または」.5と比較するとfalseが返されます.このような結論は,この比較メカニズムが仕様バージョンが後方互換性があると仮定しているためである.
インプリメンテーションのバージョン番号には、インプリメンテーションを提供する異なる組織がインプリメンテーションのバージョンを異なる定義を行うため、フォーマットが規定されていません.インプリメンテーション・バージョン間で唯一できる比較は、バージョンが同じかどうかをテストすることであり、下位互換性の仮定はありません.
パッケージは密封することができます.これは、このパッケージにクラスを追加できないことを意味します.カプセル化されていないパケットは、クラス検索パス内の複数の異なる場所からのクラスを含むことができ、カプセル化されたパケットの内容は、特定のアーカイブファイルまたはURLによって指定された場所から同じ場所から来なければならない.パッケージが密封されているかどうかを判断するには、2つの方法があります.
.public boolean issealed p:パッケージが密封されている場合はtrueoに戻ります
.public boolean issealed(URL url):パケットが所与のURLに対して密封されている場合、trueが返されます.すなわち、パケット内のクラスは、所与のURLからロードできます.パケット内のクラスが所与のURLからロードできない場合、またはパケットがシールされていない場合、falseに戻り、パケットの仕様および実装情報は、通常、パケットとともに格納されたインベントリファイルの一部として提供される.例えば、Javaアーカイブファイル(jar)のインベントリファイルの一部として、25.9.2節「アーカイブファイルjava.util.jar」で説明したように、Javaアーカイブファイル(jar)のインベントリファイルの一部として提供される.パッケージ内のクラスをロードすると、これらの情報は読み出されます.クラスローダ(ClassLoader)は、ロードするクラスのPackageオブジェクトを動的に定義します.
特定のクラスのClassオブジェクトのgetPackageメソッドを呼び出して、このクラスのPackageオブジェクトを得ることができます.指定されたパッケージ名で静的側Packageを呼び出すこともできます.getPackageは、Packageオブジェクトを取得するか、静的側Packageを呼び出す.getPackagesは、クラスローダで現在知られているすべてのパケットからなるPackage配列を返します.この2つのメソッドは、クラス・ローダのget-PackageメソッドまたはgetPackagesメソッドが呼び出されるため、コードを呼び出すクラス・ローダに関連しています.これらのクラス・ローダのメソッドは、特定のクラス・ローダとそのすべての親ローダを検索します.現在のクラス・ローダに設定がない場合は、システム・クラス・ローダが使用されます.パケットが不明な場合、クラス・ローダ・メソッドはnullを返します.パケットのタイプがロードされていないためです.