4

私は、オープンソースライブラリであり、（おそらく）他の開発者によって使用される最初の「APIjar」を書いています。Joshua Blockの効果的なAPI設計に関する論文を読みましたが、彼が話していることの1つは、アクセスを最小限に抑え、情報の隠蔽を最大化するという彼の概念です。基本的に、API開発者が使用するJavaオブジェクトにのみアクセスできるようにし、API開発者がライブラリの「ガッツ」にアクセスできないようにする必要があります。

Java開発者としての数年間、クラスを.以外のものにする必要はありませんでしたpublic。さらに、ネストされたクラスも使用したことがありません。だから私はここに座って、Java APIでこの「情報隠蔽」のベストプラクティスをどのように実装するのか疑問に思っていますか？そして、私はプライベートな、そしておそらくネストされたクラスが答えだと思います。しかし、どこから始めればよいのでしょうか。

  • すべてのソースファイルは、コンパイルするため.javaに少なくとも1つのクラスを必要とします。publicしたがって、クラスを作成するprivate（およびネストされていない）には、「クラスとバンドルする必要がありpublicます。これは、/クラスが密接に関連している場合にのみ意味があります。しかし、APIのセクションが他のアナログとは関係のないクラス（アクセシビリティを最小化する目的）で構成されていますか？publicprivateprivatepublic
  • クラスをいつprivateネストし、いつ非ネストにしますか？それとも好みの問題ですか？
4

3 に答える 3

4

パッケージプライベートである（つまり、可視性修飾子がない）クラスは、同じパッケージのクラスによってのみ表示されます。これは、APIの他のいくつかのクラスでクラスを表示できるようにする方法ですが、外部からは表示できません。

ネストされたプライベートクラスは、非パブリッククラスを作成する場合にも役立ち、その範囲はさらに狭くなります。これらは、囲んでいるクラスによってのみ表示されます。

優れたAPI設計については、Guavaのソースコードを参照することをお勧めします。そこには、内部を外部に隠すためのあらゆる種類のテクニックがあります。

于 2012-12-22T13:11:08.607 に答える
3

個人的には、私は信じていませんprivate。protected代わりに、オブジェクト指向デザインの主な利点のいくつかを考慮して、可能な限り使用します。

基本的に「情報隠蔽」の原則はガイドラインとして悪くありません。ただし、実際には、すべての場合に盲目的に従うべきではありません。-純粋な原則として、他の人が示唆しているように、インターフェイスのセットをパブリックとして定義し、パッケージプライベートクラスやファクトリメソッドなどで残りのライブラリをすべて非表示にする必要があります。Javaのパッケージプライベートの可視性には、多くの場合、Javaをやや役に立たないものにするいくつかの問題があることを考えると（-ライブラリ内のクラスはパッケージ間で協力したいと思うでしょう-）、これはそのようなアプローチを妨げるようです。

さらに、APIには常に少なくとも2つのタイプのユーザーがあります。提供するオブジェクトとメソッドを使用する基本ユーザーと、継承によってAPIの動作を（少なくとも）変更する必要がある複雑な要件を持つユーザーです。 、多くの「隠された」ものがうまく防止します。

恥ずかしがらずに、意味のpublicあるものをprotected作成し、実際には必要のないものを作成し、直接関連するコード以外から直接アクセスした場合に害を及ぼす可能性のあるpublicものだけを作成します。private

別の注意：非表示の原則は、他の人によるコードの使用を簡素化し、その正しい使用を暗示して奨励することを主な目的としています。ただし、これを実現するためのもう1つの重要な手段はドキュメント化であることを忘れないでください。とにかく、ライブラリにはドキュメントが必要になります。-100個のパブリックメソッドがあり、それらの10個がユースケースに必要であるとドキュメントに記載されている場合、ライブラリのユーザーは、それらの10個だけが表示されている場合と同じようにうまくいくでしょう。

于 2012-12-22T15:57:12.393 に答える
1

私はプライベートを信じています。私はかなり長い間フレームワーククラスに取り組んできましたが、Joshuaは、できるだけ非表示にする必要があると言っています。その背後にある理由は、公開するすべてのものが使用されるためです。そして、一度使用すると、クライアントコードを壊さずに変更することはできません。プライベートではないものはすべて、クライアントからアクセスできます。基本的に、パッケージプライベートクラスを使用し、有用な場合にのみ継承を許可し、libを有用にするために絶対に必要なクラスのみをパブリックにする必要があります。機能を拡張する場合、「インターフェイス分離の原則」が最適です。

于 2012-12-22T16:37:02.030 に答える