C++から見れば多重継承を許さない代わりにI/Fができたように思えるかもしれないけど、 私の感覚ではクラスとI/Fは意味的に違うのでメソッドをもったからクラスでいいじゃないかという感覚はないなぁ。 クラスは関連性があるがI/Fは関連性はない(操作方法が同じだというだけ)。 たとえばUNIXはすべてをファイルのように扱えるようにしている(インターフェース)が、デバイスやプロセスは結局のところファイルではない。なのでデバイスやプロセスの親クラスとしてファイルを据えたくない。「is-a」の関係性でいえば「プロセス is not a ファイル」だから。
インタフェースへのデフォルト実装はキモい (スコア:1)
実装を定義できたら抽象クラスと同じじゃない
だったら最初からinterfaceなんか作らずにclassの多重継承を認めればよかった
Re: (スコア:0)
Re: (スコア:0)
よし、abstract interfaceを作ろう
Re: (スコア:0)
meta meta プログラミング
Re: (スコア:0)
そう、オレも思った。
Abstractと比べて何が違うと言うか、どういうメリットがあって、どう使い分ければいいんだと。
あくまでラムダ式使う時はInterfaceじゃないとダメということか?
というか、ラムダ式もいちいち別でInterfaceの定義を書くのが面倒なんだけど。
単純にメソッドをオブジェクトとして扱えるようにして欲しかった。
他の言語で言うクロージャとか、Ojbective-Cのブロックのように。
Re: (スコア:0)
激しく同意します。
それ思ってるの、私だけじゃなかったんだ……良かった。
実際問題、抽象クラスとどう使い分けるべきなんだろうね?
Javaに詳しい人の回答求む。
Re: (スコア:0)
Scalaのtraitの影響でしょ。あるいはrubyのmix-inとか。抽象クラスとの使い分けは今までと変わらないでしょ。
まあデフォルト実装に関しては、実装するクラスへの影響を考えて、より注意が必要になるだろうけど。
Re: (スコア:0)
私の感覚ではクラスとI/Fは意味的に違うのでメソッドをもったからクラスでいいじゃないかという感覚はないなぁ。
クラスは関連性があるがI/Fは関連性はない(操作方法が同じだというだけ)。
たとえばUNIXはすべてをファイルのように扱えるようにしている(インターフェース)が、デバイスやプロセスは結局のところファイルではない。なのでデバイスやプロセスの親クラスとしてファイルを据えたくない。「is-a」の関係性でいえば「プロセス is not a ファイル」だから。
Re: (スコア:0)
>たとえばUNIXはすべてをファイルのように扱えるようにしている(インターフェース)が、
インターフェイスの文脈でいうのなら、「ファイルのように扱える」は間違い。「ファイルハンドルでアクセスできる」でしょ。
>デバイスやプロセスは結局のところファイルではない。
当たり前。
「ファイルハンドルでアクセスできる」というインターフェイスを実装した全く別のクラスだから。
インターフェイスは直行性があって、クラスは直行性がないことを言いたいんだろうけど、例えが不適切なせいで、内容が伝わらない。
Re: (スコア:0)
> 「ファイルハンドルでアクセスできる」でしょ。
違う。UNIXの設計思想としてファイルであるかのように振る舞うのがUNIXらしさである。ファイルハンドルを介するなど手段に過ぎない。
>>デバイスやプロセスは結局のところファイルではない。
> 当たり前
伝わってるじゃない。
Re: (スコア:0)
Re:インタフェースへのデフォルト実装はキモい (スコア:1)
Re: (スコア:0)
C++から見ると、操作方法が同じだけならテンプレートでいいじゃんとなる。
必要のメソッドを実装してさえいれば全く無関係のクラスを受け取れる。わざわざクラスに継承関係を加える必要がない。
Re: (スコア:0)
そんなに大きな主語の話ではないと思います。(この場合、大きな主語だから悪いとか非難してる話では無いです。)
C++だと、どのクラスか付記すれば関数はどこでも書けますが、Javaだと、Classの波括弧の中にしか書けません。
それでは不便なので、別のところ(インターフェースの波括弧の中)にも書ける様にしたというだけでは無いでしょうか?
もちろんC++みたいに、どこでも書ける様にすればより柔軟性が増すでしょうけど、それではJavaの挟持に反すると
いうものでしょう。