- - PR -
interface のメソッドは、なぜ protected にできないのでしょうか?
| 投稿者 | 投稿内容 | ||||
|---|---|---|---|---|---|
|
投稿日時: 2003-08-25 21:19
私も以前は、何でinterfaceはprotectedなメソッドを宣言できないのだろうかと思い悩んだことがあります。
しかし、今は、骨格実装抽象クラスの存在を知り、protectedなメソッドは骨格実装抽象クラスで定義(宣言）すれば良く、interfaceには必要ないと思っています。 protectedなアクセス制限は、カスタマイズ可能な内部仕様（実装の詳細）であり、 抽象クラスに定義することは、理にかなっていると考えています。 尚、骨格実装抽象クラスについての詳細は、Effective Javaに書かれています [ メッセージ編集済み 編集者: かずくん 編集日時 2003-08-25 21:33 ] | ||||
|
投稿日時: 2003-08-25 23:07
もし Java の class が多重継承を認めていたとしも、interface は存在し、
protected には出来ないようになっていたのではないでしょうか。 なぜなら、インターフェースの目的はアーキテクチャの実装とインプリメン テーションの実装を分離することにあるからです。 Java の interface はアーキテクチャの実装を担っているのですから、 private や protected などのインプリメンテーションを干渉する アクセス修飾子を使用するのは、本来の目的から外れてしまいます。 そのため、public しか使えないのだと思います。 #用語の使い方が間違っていたらすみません。下記の意味で使いました。 #アーキテクチャ・・・どんな構造かを語るもの #インプリメンテーション・・・どのように実現するかを語るもの | ||||
|
投稿日時: 2003-08-26 08:42
私はインターフェースがpublicなものしか持てないということがあまり理由の無いことだ
と思っています. その理由として 1.インターフェースでprotectedなメソッドを持たずに骨格抽象クラス(実はeffective java は読んだことがありませんのでその内容は知らないのですが, 少なくともインターフェース ではないと想像します)で実装したとしても多重継承はできない. 従ってprotected なメソッドを持つinterfaceの代用にはならない. 2.インターフェースはネストしたクラスをもてます.(static な内部のクラス) インターフェース内のネストしたクラスはなぜかpublic でなければならず,また ネストしたクラス内では普通にprivateやprotectedな属性のメンバを持てる. にもかかわらずネストしたクラスから参照するインターフェースのstatic final な データ属性はそれがインターフェース外に対して隠蔽されるべきものであっても publicにしなければならない. これはインターフェースのメンバをpublicに限定する理由の正当性を著しく疑わせる ものです 簡単な言語というものは直交性に富んでおり, その場合によって異なる理由付けが必要に なるようなものであるべきでないと考えますが, いかがでしょう むしろこのような(interfaceのメンバ属性をpublicに限定するというような)制限 はコンパイラは簡単にしても言語としては複雑になるだけで利益が無いように思うの ですが | ||||
|
投稿日時: 2003-08-26 09:48
| ||||
|
投稿日時: 2003-08-26 11:32
ども、ほむらです。
質問を混ぜ返すようで申し訳ないのですが。。。 ----------- そもそも、implementsって継承に含まれるのでしょうか？ 私的な解釈だとクラスの場合、extendsは拡張という 名前のとおり継承という動作であると思います。 でも、インターフェイスの場合 implements 実装(？)という 名前からでは継承という動作とどうも一致しません＾＾;;;;; あくまで実装の付加という意味合いが強いのではないかなと。。。。 つまり、継承しているというよりもクラス内部で別途宣言している感じですか。。。 (もう少し親密ですけど＾＾;;;;) こう考えた場合、インターフェイスとの継承関係は存在しなくなってしまうので インターフェイス側でprotectedの宣言をしてもimplementsで追加したクラス側には アクセス権限もってないんじゃないかなとおもうのですが考えすぎてしょうか？ | ||||
|
投稿日時: 2003-08-26 15:26
でも、public以外のinterfaceのメソッドを許すと、interfaceを
使用する旨みが半減してしまうように思うのですが、、、 interface A 型の変数のBメソッドを、利用する側は、必ず使えるとは 限らなくなってしまうんですよね？ そうなると、interfaceを使用して、実装によらず、アクセス手段を 公開する、interfaceの働きが保証できなくなってしまうのではないでしょうか？ | ||||
|
投稿日時: 2003-08-26 17:32
ども、ほむらです。
先ほどは書き忘れましたが僕もinterfaceにはpublicのみで十分と思っています。 Jun氏の意見とは正反対になってしまうのでちと心苦しくも思いますが public以外である理由もまたないかなと。。。 ---------------- さてさて、毎度の事ながら僕の発言は横道にそれがちですが 後学のためにということでご容赦＞＜ (独り言とも言うかも(笑 JAVAを勉強し始めてまだまだ時間も短いですが 僕の認識としてもclassとinterfaceはまったく別のものだと思っています。 宣言の過程においては類似点が多いのかとも思いますけれども interfaceは’ある機能を提供するための機能セットの定義’と認識しているので 隠蔽はおろか実装も不可能なのではないかと思います。 ＃ ちなみに、interfaceを英和で引くと共有領域という意味があるみたいです なぜなら、機能としての操作を隠蔽するのであれば それは機能を取り込んだ先のオブジェクトで実装すればよいということであると思うし。 実装についても機能について固定的な操作しかできないのであれば それはやはり、機能セットとしてでなく取り込んだ先のオブジェクトで 実装すべきではないかなと、、、、 ん〜上手に表現できないところが残念なのですが classで定義するのが何をするのか に対して interfaceで定義するのは何をさせるかのか(機能としての必要項目？？) だと思います。 (abstract classならば何をして拡張後に何をさせるのかとか？) ＃ 多重継承ってそんなにメリットのあるものなのですか？ ＃ Ｃ＋＋で作っていた時代はメンバ変数に取り込んで ＃ アクセス用のラッパーを作るだけで一度も使用したことがないのですが･･・・・ | ||||
|
投稿日時: 2003-08-26 17:32
まず、意見を整理していいですか？
protected希望派の意見は「仕組みとして」付けようと思えば付けられるのでは？という 立場ですが、否定派は「意味合いの上で」やられては矛盾が生じるという主張です。 そもそも着眼点が違うので、互いの意見がかみ合っていないのも道理です。 で、私は否定派です。 Javaにもオブジェクト指向に準拠していない、実装上の妥協部分があるわけですが、 それを例にとってinterfaceの根本的な役割も曲げてしまうというのは、 少々乱暴だと思います。 この場合、場当たり的にinterfaceにprotectedを追加するのではなく、 骨格抽象クラスを多重継承できるように改善されるべきだと考えます。 | ||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。