2011-07-10 10 views
11

私はライブラリとして提供したいアプリケーションをJava MEで開発しています。誰もが使いたくないクラスを隠す方法はありませんが、図書館が機能するためには不可欠です。Javaライブラリを提供していますが、クラスを隠しています

更新: 私は公開指定子を省略できますが、別のパッケージを作成せずに開発中にライブラリ自体を構築するにはどうすればよいですか?異なるパッケージを異なるフォルダとして表示するのが好きです。これにより、コードを適切な方法で構造化することができます。しかし、いくつかのケースでは、他のパッケージのクラスにアクセスする必要があるかもしれないので、これはややこしいことです。パッケージは本当に何を表していますか?一つのアイデアは "インターフェース"を作ることかもしれませんが、これは公に宣言されなければならないので、外国人はライブラリ内のいくつかのプロセスだけを意図したインターフェースを実装するかもしれません。

+0

は、彼らが "最終" してください。 – daGrevis

+2

クラスをfinalにすると、サブクラス化のみが禁止されます。それはまだ露出されます。 – thunderflower

+0

あなたは「欲しい」という意味とあなたが行きたいと思う問題に依存します。アクセス修飾子は、例えばリフレクションで回避するのが簡単です。 – CurtainDog

答えて

-3

公開したくないクラスを保護する必要があります。これにより、クライアントコードからは使用できなくなります。 the official docs

+0

必要な部分:クラス宣言に 'public'キーワードを入れないと、クラスは同じパッケージ内の他のクラスからのみアクセスできます。 – Brabster

+1

クラスの 'protected'修飾子は、メンバーのためにのみ使用できません。クラスへのアクセスを制限する唯一の方法は、 'public'修飾子を省略して、パッケージ内でのみ可視にすることです。 – Muzikant

1

同じパッケージ内の他のクラスだけが見ることができるクラスpackage protectedを作ることができます。 これが実現できない場合は、ProGuardを使用してクラスをマングルし、その実装を隠すことができます。

+0

ありがとうございます、はい、私はProGuardを調べます –

+0

クラスのために 'protected'修飾子を使用することはできません。クラスへのアクセスを制限する唯一の方法は、 'public'修飾子を省略して、パッケージ内でのみ可視にすることです。 – Muzikant

0

はい、あります。

これらのクラスを宣言しないでください。public。言い換えれば、そのようpublicキーワードを省略します。デフォルトでは

class Internal { // rather than "public class Internal" 
    ... 
} 

、クラスは、彼らだけが定義されているパッケージ内にアクセスできます。

0

例を考えてみましょう:

あなたは、クラスAの機能を使用して非表示にしたいというクラスA、クラスBを、持っている場合は、あなたがこれを行うことができます:

class B{ 
//Attribute and Methods 

    //Inner class A 
    class A{ 
     //Methods and Attributes. 
    } 

} 

これを実行した後、クラスBのメソッドの内部にクラスAのオブジェクトを作成して使用することができます。クラスは他のクラスから隠されていますが、それでも使用できます。

+0

クラスを内部にすることは、それを外部の世界から隠すことはありません。それをインポートして使用することはできます。ただし、使用したパッケージレベルのアクセスは、クラスを他のパッケージから隠すことになります。 –

4

ライブラリーAPIを設定する場合は、 を公開したくない場合は保護する必要があります。これは単なるアクセス修飾子を省略しないでください:

class fooBar { 
    // do stuff here  
} 

これは、サブクラス fooBar任意のクラスからだけでなく、同じパッケージ内 からのアクセスを可能にする「デフォルト」としてクラスのアクセスを設定します。

クラス内では、メソッドとメンバーのアクセスをすべてprivateprotectedとマークするか、修飾子を省略して必要に応じて「デフォルト」にすることで、アクセスをロックする必要があります。

  • privateは、包含クラスからのアクセスのみを許可します。
  • 'default'(修飾子なし)は、包含クラス内でパッケージを含むことができます。
  • protectedは、同じクラス、パッケージ、およびすべてのサブクラスからのアクセスを許可します。あなたが露出している何のために

public)また、上書きされるように設計されていない場合finalとしてそれをマークすることをお勧めします。

基本的にできる限りすべてをロックします。 APIのサイズが小さくなればなるほど使いやすく、破損しにくくなります。将来的に何かが露呈される必要があると感じたら、将来それをしてください。 APIの一部を非難するのではなく、むしろAPIを拡張するほうがはるかに簡単です。

+2

ありがとう!しかし、あなたが言うように、私はクラスfooBarを同じパッケージ内からのみ使用できます。 Javaプロジェクトを構造化する通常の方法は何ですか?私はクラスが持つさまざまなものに基づいてパッケージを作成しています。例えば、私はcom.commsという1つのパッケージを持っています。ここで私はソケット経由で送信するためのルーチンとクラスを格納しています。次に、commsパッケージを使用する別のパッケージ(アプリケーションレベルなど)があります。しかし、私はこのようなAPIを作成するために、すべてのクラスを同じパッケージの中に入れなければならないと思いますか? –

+3

はい、複数のパッケージを持つライブラリを持っているとどうしますか? –

+0

デフォルトでは、クラスにはデフォルトの可視性があるため、可視性はパッケージ内にのみあります。明示的に保護されるように設定することもできますし、同じ目的にも役立ちます。 – Tarun

0

Java 9が可能な場合は、Jigsaw modulesを使用してください。そうでない場合は、すべてのクラスを隠しクラスのパッケージレベルのアクセス権を持つ同じパッケージに配置し、Maven modulesを使用してそれらを整理します。

私のプロジェクトでは、coronataというWiiリモコンのJavaライブラリを使っています。ほとんどすべてのクラスはパッケージcom.github.awvalenti.bauhinia.coronataにありますが、異なるモジュール(IDE上のプロジェクトとして表示されます)にあります。

公開クラスは公開されています。彼らは、モジュールにあります。

  • coronata-api
  • coronata-builder
  • coronata-demos
  • coronata-lib

隠しクラスは、パッケージレベルのacesssを持っています。彼らは、モジュールにあります。

  • coronata-common
  • coronata-implementation-bluecove
  • coronata-implementation-wiiusej
関連する問題