C++から見れば多重継承を許さない代わりにI/Fができたように思えるかもしれないけど、 私の感覚ではクラスとI/Fは意味的に違うのでメソッドをもったからクラスでいいじゃないかという感覚はないなぁ。 クラスは関連性があるがI/Fは関連性はない(操作方法が同じだというだけ)。 たとえばUNIXはすべてをファイルのように扱えるようにしている(インターフェース)が、デバイスやプロセスは結局のところファイルではない。なのでデバイスやプロセスの親クラスとしてファイルを据えたくない。「is-a」の関係性でいえば「プロセス is not a ファイル」だから。
インタフェースへのデフォルト実装はキモい (スコア:1)
実装を定義できたら抽象クラスと同じじゃない
だったら最初からinterfaceなんか作らずにclassの多重継承を認めればよかった
Re: (スコア:0)
私の感覚ではクラスとI/Fは意味的に違うのでメソッドをもったからクラスでいいじゃないかという感覚はないなぁ。
クラスは関連性があるがI/Fは関連性はない(操作方法が同じだというだけ)。
たとえばUNIXはすべてをファイルのように扱えるようにしている(インターフェース)が、デバイスやプロセスは結局のところファイルではない。なのでデバイスやプロセスの親クラスとしてファイルを据えたくない。「is-a」の関係性でいえば「プロセス is not a ファイル」だから。
Re: (スコア:0)
>たとえばUNIXはすべてをファイルのように扱えるようにしている(インターフェース)が、
インターフェイスの文脈でいうのなら、「ファイルのように扱える」は間違い。「ファイルハンドルでアクセスできる」でしょ。
>デバイスやプロセスは結局のところファイルではない。
当たり前。
「ファイルハンドルでアクセスできる」というインターフェイスを実装した全く別のクラスだから。
インターフェイスは直行性があって、クラスは直行性がないことを言いたいんだろうけど、例えが不適切なせいで、内容が伝わらない。
Re:インタフェースへのデフォルト実装はキモい (スコア:0)
> 「ファイルハンドルでアクセスできる」でしょ。
違う。UNIXの設計思想としてファイルであるかのように振る舞うのがUNIXらしさである。ファイルハンドルを介するなど手段に過ぎない。
>>デバイスやプロセスは結局のところファイルではない。
> 当たり前
伝わってるじゃない。