- - PR -
interface のメソッドは、なぜ protected にできないのでしょうか?
| 投稿者 | 投稿内容 | ||||||||
|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2003-07-11 15:56
unibon です。こんにちわ。
その後、Java Language Specification Second Edition http://java.sun.com/docs/books/jls/second_edition/html/interfaces.doc.html をチラッと見てみたのですが、 なぜメソッドが public だけなのかは理由が分かりませんでした。 とても とても とても とても恐れ多いのですが、言語仕様を作った人々、 http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html が、public 以外がありうることをついウッカリ忘れてしまっていた、 という、ただそれだけ、のような気がしてなりません。 ＃たとえ、万が一そうだったとしても、責めているわけではありませんので。 昔は、内部クラスの仕組みもなかったので、気づかなかったのでしょう。 ＃と、もう、決め付けてしまっていますが。 
| ||||||||
|
投稿日時: 2003-07-11 16:29
unibonさんの書き込み (2003-07-11 15:56) より:
>とても とても とても とても恐れ多いのですが、言語仕様を作った人々、 http://java.sun.com/docs/books/jls/second_edition/html/j.title.doc.html が、public 以外がありうることをついウッカリ忘れてしまっていた、 という、ただそれだけ、のような気がしてなりません。 他の方も触れていますが、interfaceはオブジェクトの外部仕様を規定するためのもの なので、publicしかなくて当然だと思うのですが。そもそもの目的と違う用途に使えない かたと言って言語仕様をどうこういうのはおかしくないですか? | ||||||||
|
投稿日時: 2003-07-11 18:30
私も そう思うのですが、 それだと思考停止しているような気もするので理由を無理やり考えてみました。 1.このようなアクセス制限が必要な事は比較的少ないので却下された。 2.このようなアクセスを制限をしたい、という要求を聞いていると アクセス修飾子が幾つあっても足りない。例えば class A { //ここには書かないけど method は class B からだけ利用されるメソッドとする。 void method(){} public static void main(String[] args){ A a = new A(); a.method(); //これをコンパイルエラーにしたい。 B b = new B(); b.someMethod( a ); //この中で method が呼ばれる。これが method の本来の使い方。 } } というような無茶な要求があっても普通は却下しますよね。 基本的には interface は「それを実装するクラス」や 「実装クラスと同パッケージのクラス」のために存在するのでは無く、 「その interface を利用するクラス」のためにある。 そして、「その interface を利用するクラス」のパッケージを限定しないとすれば、 public しか指定できないのは当然の話なのだと思われます。 [ メッセージ編集済み 編集者: お犬様 編集日時 2003-07-11 21:09 ] | ||||||||
|
投稿日時: 2003-07-11 19:09
どうも、Wataです。
publicなインターフェースに限定指定言えば当然だと思いますし、お犬様の書き込みは非常に的を得ていると思います。 しかし、パッケージプライベート（無指定）やメンバ型としてのprivateやprotectedのインターフェイスの存在を考えると少し不便な気がします。 仮にパッケージプライベートのインターフェイスで詳細実装にかかわる（いつ変更されるかわからない）部分の型を定義したいと思います。すると、インターフェイスのメソッドはpublicにしなければならないので詳細実装のはずが、インターフェイスを実装するpublicクラスは実装メソッドをpublicにして外部にさらさなければならなくなります。そうすると、もはや後日の実装の変更は不可能になります。 こう考えると、インターフェイスのメソッドもインターフェイスと同じかそれよりも上のアクセス指定でもよいような気がします。 （つまりパッケージプライベートなインターフェイスはパッケージプライベートなメソッド、privateなインターフェイスはprivateなメソッドを定義できるってこと。） ただし、上記の問題は、実装クラスのアクセス指定をpublicにしなければいいだけなので、全然に大した問題ではありませんけどね。 
| ||||||||
|
投稿日時: 2003-07-12 00:13
unibon です。こんにちわ。
これについて Sun の Bug Database を探していたら見つけました。 http://developer.java.sun.com/developer/bugParade/bugs/4093687.html なお、このへんを探していると、私の最初の疑問と似た話として、 http://developer.java.sun.com/developer/bugParade/bugs/4144491.html http://developer.java.sun.com/developer/bugParade/bugs/4193599.html http://developer.java.sun.com/developer/bugParade/bugs/4193604.html http://developer.java.sun.com/developer/bugParade/bugs/4230610.html http://developer.java.sun.com/developer/bugParade/bugs/4456057.html などが見つかりました。 ただしこれらのページでは、内部クラスについての言及がなさそうであり、そのせいか、 public 以外のメソッドの必要性はあまり高くない、 という論調になっているような気もします。 ＃上記のページは、まだあまり良く読んでいないのですが。 あと、私の考えを補足しますと、 極端な話、interface であってもメソッドに private すら使えても良いと思います。 この場合、そのメソッドの実装が絶対にできないので、 その interface を implements している class のコンパイル時にはコンパイルエラーになりますが、 だからと言って interface の時点にまでさかのぼって private を禁止することは、 キレイだと感じません。 | ||||||||
|
投稿日時: 2003-07-12 11:58
>interface の時点にまでさかのぼって private を禁止することは、
>キレイだと感じません。 interfaceにpublic以外のメソッドを追加するために言語仕様を変更する事に 下位互換性を犠牲にするほどのメリットがあるとは思えません。 interfaceの構文に変更を加えるためには、バイトコードレベルでの変更が 必要であり、VM自体の変更が必要になるはずです。 VM自体が変更されると必然的に、interface構文変更前に書かれたプログラムは そのままでは(書き換えない限り)interface構文変更後のVMでは動作しなくなります。 つまり、interface構文を変更すると下位互換性がなくなるのです。 このことはinterface構文変更後のVMで動かすためにはinterface変更前の構文で書かれた プログラム全てを修正する必要があることを意味します。 interfaceにpublic以外のメソッドを追加するための言語仕様変更に下位互換性を 犠牲にしてまで行うほどのメリットがあるとは思えないのですが、下位互換性を 犠牲にしてもよいほどのメリットがあるのならぜひ教えてください。 | ||||||||
|
投稿日時: 2003-07-12 12:46
unibon です。こんにちわ。
大きなメリットはないです。しいてあげるとしたら、つぎの2点位でしょうか。 (1) 初心者が理解し易くなる。 もし private/protected があったほうが理論的にスッキリするのならば(という仮定がありますが)、 私のように、どうして interface に private/protected がないのか、を悩まなくて済みます。 教えるほうも、class と interface の類似性をより強調できて、楽になります。 (2) 将来、Java を大幅に拡張・変更する機会(C# なども含む  )があったときに、
『ああ、そういえばそんな RFE(Request for Enhancement) があったなあ。これも足しとくか。』 となるかもしれません。 言語仕様や VM 仕様を変えるかどうかは、また別に考えれば良いと思います。 初期の C++ が C にコンバータ(?)のようなものを追加していたような感じや、 あるいは単に IDE(統合開発環境)上でだけ、あたかも private/protected が使えるように見せかけるだけ、 などのように、言語仕様や VM 仕様を変えずにできる可能性もありますし。 ＃でも、良くありがちな、コメントや命名規則でやりくりするのは、 ＃個人的な好き嫌いとしてはややこしくてイヤだ(笑)。 もっともたかが(と言ってしまうとみもふたもありませんが)、 private/protected のためにそこまでしなくても、単に開発者が頭の中で、 『これ、ホントはこっちのほうが良いんだけど、過去の経緯でこうなってるんだったなあ』 と置換するだけでも良いです。 ＃以下、追加。 あと、下位互換性(backward compatibility)についてですが、 たとえば JDK 1.4 のデフォルトの設定で生成した .class ファイルは、 ファイルのフォーマットが違うため、古い JDK の環境では動かないことがありますし、 あと、シリアライズなども下位互換性がなかったと思います (フォーマットは -target オプションを付けてコンパイルすればよいし、 シリアライズについては VM とは無関係かもしれませんが)。 だから、下位互換性はなくても良いと思います。 ＃もちろんあったほうが良いけど、もうすでにないので、 ＃private/protected の場合もさほど拘らなくてよいのでは、という意味です。 [ メッセージ編集済み 編集者: unibon 編集日時 2003-07-12 12:58 ] | ||||||||
|
投稿日時: 2003-07-12 14:54
| ||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。