- PR -

インタフェースと抽象クラスの混合は問題ない?

投稿者投稿内容
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-06-10 21:20
引用:

lalupin4さんの書き込み (2006-06-10 10:29) より:
1. 「「継承」は結合度が最も高い概念。」なのでAbstの抽象度はIInterと同一か、低い。
2. 継承ツリー上Abstより上にIInterがあればAbst.Hoge()をジャンプできる。


1. 派生したクラスから見て、抽象度を測ること自体意味がありません。
2. 意味がよく分かりません。

引用:

lalupin4さんの書き込み (2006-06-10 10:29) より:
1. 「その」Func()を使う、に対してIInteとAbstの抽象度は抽象度は同一。
2. 「どの」Func()を使う、に対してIInterの抽象度はAbstと同一か、高い。


意味がよく分かりません。その根拠は何でしょうか。

interface と abstract を比べて、より interface を使った方がよいなんて、非常にナンセンスです。
それぞれ使うべきシナリオがあるでしょう。

引用:

 くっそう…。System.ObjectがSystem.IObjectの実装クラスだったら
議論の余地はないのに…。
とか思ってみたり。


くっそう…。System.Object は何で抽象クラスじゃないんだ…。
インスタンス化しても意味ないのに…。抽象なメソッド(インターフェース)が存在しないからか…。
_________________
囚人のジレンマな日々
lalupin4
大ベテラン
会議室デビュー日: 2004/07/26
投稿数: 163
投稿日時: 2006-06-10 23:04
引用:

囚人さんの書き込み (2006-06-10 21:20) より:
意味がよく分かりません。

分かってお願い。あなたならきっとできるはず。
http://blogs.wankuma.com/shuujin/archive/2006/06/06/30040.aspx

引用:
くっそう…。System.Object は何で抽象クラスじゃないんだ…。
インスタンス化しても意味ないのに…。抽象なメソッド(インターフェース)が存在しないからか…。


するよ。
コード:
public interface IObject
{
    bool Equels(object obj);
    int GetHashCode();
    Type GetType();
    string ToString();
}

http://msdn2.microsoft.com/ja-jp/library/system.object(VS.80).aspx
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-06-10 23:33
引用:

lalupin4さんの書き込み (2006-06-10 23:04) より:
するよ。


「抽象なメソッド(インターフェース)が存在しないからか…。 」に対する答えだと判断します。

その通りです。System.Object は interface でも、abstract でもない「具象クラス」ですが、明確な「インターフェース」が存在します。(本来なら、System.Object は抽象クラスでも良かったのではないか、と私は考えていますが)
System.Object を継承するクラスは、System.Object のインターフェースを持っているという事になります。

ここで、「出来る限り abstractより interface を使う方が良い」を適用すると、System.Object より System.IObject を使う方が良い、という事になりますが、果たしてそうでしょうか。

何度も言いますが、abstract と interface を比較して、interface の方が良い、というのは意味がないのです。
_________________
囚人のジレンマな日々
なちゃ
ぬし
会議室デビュー日: 2003/06/11
投稿数: 872
投稿日時: 2006-06-11 00:10
引用:

囚人さんの書き込み (2006-06-10 23:33) より:
ここで、「出来る限り abstractより interface を使う方が良い」を適用すると、System.Object より System.IObject を使う方が良い、という事になりますが、果たしてそうでしょうか。

何度も言いますが、abstract と interface を比較して、interface の方が良い、というのは意味がないのです。


はっきり言って多分にインターフェイス以外は多重継承できないって言う、
現実の制約から来てる話だと思うんですけどね。

インターフェイスより抽象クラスの方が制約が大きくなるので、
特に理由が無いか迷う場合はインターフェイスの方が無難ってね。

でObjectは必ず継承されるわけなので、これがインターフェイスでなくても
現実は困らない。
まあそもそも既定の実装が必要(無いとやってられない)ので
インターフェイスにすると困るだけでしょうけど。

抽象クラスになってないのはなぜでしょうね。
何らかの理由でObject自体のインスタンスを作成できる必要がある状況があった、
あるいは、そういう状況や単なるObjectがほしいなケースは想定されるので、
そういう場合に便利なように制約はゆるい方にしておいた。
※同期インスタンスとかようにはよくObjectのインスタンスは使ったりしますね。
demanotto
会議室デビュー日: 2004/07/29
投稿数: 4
投稿日時: 2006-06-11 00:31
誤解を恐れずに書くと、

コンセント=Interface
コンセントに挿す

ドライヤー=Abstract Class で implements コンセント
きれいなお姉さんのドライヤー extends ドライヤー

テレビ=Abstract Class で implements コンセント
プラズマテレビ extends テレビ

で使い方は、
class コンセントに挿したい
コンセント ドライヤー = new きれいなお姉さんのドライヤー();
コンセント テレビ = new プラズマテレビ();
ドライヤー.コンセントに挿す;
テレビ.コンセントに挿す;

なわけです。わかりにくい説明ですいません。

つまり、
Interfaceはできなくてはならないこと(動詞)、
Abstract Classは大雑把にそれは何なのか(名詞もしくは目的語)。

まぁ、当てはまらない場合も多いわけですが。
JavaのSpringフレームワークとかコレクションフレームワークを見るとなるほどと思えたりしますね。
GoFでググってみたりデザインパターンを調べたりすると自ずと使い分けができるような気がします。
囚人
ぬし
会議室デビュー日: 2005/08/13
投稿数: 1019
投稿日時: 2006-06-11 02:24
引用:

はっきり言って多分にインターフェイス以外は多重継承できないって言う、
現実の制約から来てる話だと思うんですけどね。

インターフェイスより抽象クラスの方が制約が大きくなるので、
特に理由が無いか迷う場合はインターフェイスの方が無難ってね。


多分そうでしょうね。
ただ、それでも .NET では多重継承はできないのが現実です。(.NET 言語でも多重継承できるのはある)
多重継承しているように見えるのは、ただ多くのインターフェースを「実装」しているに過ぎません。

引用:

抽象クラスになってないのはなぜでしょうね。
何らかの理由でObject自体のインスタンスを作成できる必要がある状況があった、
あるいは、そういう状況や単なるObjectがほしいなケースは想定されるので、
そういう場合に便利なように制約はゆるい方にしておいた。
※同期インスタンスとかようにはよくObjectのインスタンスは使ったりしますね。


私も過去の自分のブログで書きましたが、同期インスタンスぐらいしか思いつきませんでした。
_________________
囚人のジレンマな日々
まいるどきゃっと
大ベテラン
会議室デビュー日: 2004/08/12
投稿数: 135
お住まい・勤務地: 群馬
投稿日時: 2006-06-11 05:29
引用:

なちゃさんの書き込み (2006-06-11 00:10) より:

抽象クラスになってないのはなぜでしょうね。



ぱっと思いつきでは、

1. わざわざ抽象クラスにする理由がないから。
2. abstractにする必要があるメソッドがないから。
3. 変な制限を開発者にかけたくないから。

とか。

# あくまで単なる思い付きで、何の考察もしてません
まいるどきゃっと
大ベテラン
会議室デビュー日: 2004/08/12
投稿数: 135
お住まい・勤務地: 群馬
投稿日時: 2006-06-11 06:00
引用:

R・田中一郎さんの書き込み (2006-06-10 08:58) より:

手元にある「C#コーディング標準(C)河端善博氏」という例のブツによると、P13の(39)に次のように書いてありました(^^;

-------------/ 引用開始 /-------------------
抽象クラス(abstract Class)はなるべく使わず、interface を多用せよ。abstract Classは、一部実装があり、一部抽象メソッドであるような場合にのみ使う。

理由:interface は幾つでも継承できるが、Classは1つだけ。1つから継承してしまうと、もう継承できずもったいない。
-------------/ 引用終了 /-------------------

ここから来ているのかな〜?と勝手に推測してみる・・・



このドキュメントは、オブジェクト倶楽部が作成した『Javaコーディング標準』をC#版に直したものですよね。元となった『Javaコーディング標準』は、Javaプログラマ必読書『Effective Java』の「抽象クラスよりインタフェースを選ぶ」という項目を踏まえてR・田中一郎さんが引用した部分を記述したのだと思われます。

『Javaコーディング標準』では理由を簡潔に述べるためにそのような記述になっていますが、『Effective Java』の方は、いくつかの項目で継承というシステムの問題点を挙げた上で単純な継承よりもコンポジションやMix-inなどの形にすることを勧めています。

がらすさんの言う「出来る限りインタフェースを使った方が良い」ってのは、このあたりから来ているのでは?と思ってます。

スキルアップ/キャリアアップ(JOB@IT)