- - PR -
インタフェースと抽象クラスの混合は問題ない?
投稿者 | 投稿内容 | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2006-06-10 21:20
1. 派生したクラスから見て、抽象度を測ること自体意味がありません。 2. 意味がよく分かりません。
意味がよく分かりません。その根拠は何でしょうか。 interface と abstract を比べて、より interface を使った方がよいなんて、非常にナンセンスです。 それぞれ使うべきシナリオがあるでしょう。
くっそう…。System.Object は何で抽象クラスじゃないんだ…。 インスタンス化しても意味ないのに…。抽象なメソッド(インターフェース)が存在しないからか…。 _________________ 囚人のジレンマな日々 | ||||||||||||
|
投稿日時: 2006-06-10 23:04
http://blogs.wankuma.com/shuujin/archive/2006/06/06/30040.aspx
するよ。
| ||||||||||||
|
投稿日時: 2006-06-10 23:33
「抽象なメソッド(インターフェース)が存在しないからか…。 」に対する答えだと判断します。 その通りです。System.Object は interface でも、abstract でもない「具象クラス」ですが、明確な「インターフェース」が存在します。(本来なら、System.Object は抽象クラスでも良かったのではないか、と私は考えていますが) System.Object を継承するクラスは、System.Object のインターフェースを持っているという事になります。 ここで、「出来る限り abstractより interface を使う方が良い」を適用すると、System.Object より System.IObject を使う方が良い、という事になりますが、果たしてそうでしょうか。 何度も言いますが、abstract と interface を比較して、interface の方が良い、というのは意味がないのです。 _________________ 囚人のジレンマな日々 | ||||||||||||
|
投稿日時: 2006-06-11 00:10
はっきり言って多分にインターフェイス以外は多重継承できないって言う、 現実の制約から来てる話だと思うんですけどね。 インターフェイスより抽象クラスの方が制約が大きくなるので、 特に理由が無いか迷う場合はインターフェイスの方が無難ってね。 でObjectは必ず継承されるわけなので、これがインターフェイスでなくても 現実は困らない。 まあそもそも既定の実装が必要(無いとやってられない)ので インターフェイスにすると困るだけでしょうけど。 抽象クラスになってないのはなぜでしょうね。 何らかの理由でObject自体のインスタンスを作成できる必要がある状況があった、 あるいは、そういう状況や単なるObjectがほしいなケースは想定されるので、 そういう場合に便利なように制約はゆるい方にしておいた。 ※同期インスタンスとかようにはよくObjectのインスタンスは使ったりしますね。 | ||||||||||||
|
投稿日時: 2006-06-11 00:31
誤解を恐れずに書くと、
コンセント=Interface コンセントに挿す ドライヤー=Abstract Class で implements コンセント きれいなお姉さんのドライヤー extends ドライヤー テレビ=Abstract Class で implements コンセント プラズマテレビ extends テレビ で使い方は、 class コンセントに挿したい コンセント ドライヤー = new きれいなお姉さんのドライヤー(); コンセント テレビ = new プラズマテレビ(); ドライヤー.コンセントに挿す; テレビ.コンセントに挿す; なわけです。わかりにくい説明ですいません。 つまり、 Interfaceはできなくてはならないこと(動詞)、 Abstract Classは大雑把にそれは何なのか(名詞もしくは目的語)。 まぁ、当てはまらない場合も多いわけですが。 JavaのSpringフレームワークとかコレクションフレームワークを見るとなるほどと思えたりしますね。 GoFでググってみたりデザインパターンを調べたりすると自ずと使い分けができるような気がします。 | ||||||||||||
|
投稿日時: 2006-06-11 02:24
多分そうでしょうね。 ただ、それでも .NET では多重継承はできないのが現実です。(.NET 言語でも多重継承できるのはある) 多重継承しているように見えるのは、ただ多くのインターフェースを「実装」しているに過ぎません。
私も過去の自分のブログで書きましたが、同期インスタンスぐらいしか思いつきませんでした。 _________________ 囚人のジレンマな日々 | ||||||||||||
|
投稿日時: 2006-06-11 05:29
ぱっと思いつきでは、 1. わざわざ抽象クラスにする理由がないから。 2. abstractにする必要があるメソッドがないから。 3. 変な制限を開発者にかけたくないから。 とか。 # あくまで単なる思い付きで、何の考察もしてません | ||||||||||||
|
投稿日時: 2006-06-11 06:00
このドキュメントは、オブジェクト倶楽部が作成した『Javaコーディング標準』をC#版に直したものですよね。元となった『Javaコーディング標準』は、Javaプログラマ必読書『Effective Java』の「抽象クラスよりインタフェースを選ぶ」という項目を踏まえてR・田中一郎さんが引用した部分を記述したのだと思われます。 『Javaコーディング標準』では理由を簡潔に述べるためにそのような記述になっていますが、『Effective Java』の方は、いくつかの項目で継承というシステムの問題点を挙げた上で単純な継承よりもコンポジションやMix-inなどの形にすることを勧めています。 がらすさんの言う「出来る限りインタフェースを使った方が良い」ってのは、このあたりから来ているのでは?と思ってます。 |