抽象クラスとインターフェースの存在意義について、下記の人を対象に

簡単に3行くらいで説明するとしたら、どのように言えばよいでしょうか?

対象:ある程度プログラミングに精通した方(VB6コーディング経験あり)で
クラスなどはあまり作ったことがない方

回答の条件
  • URL必須
  • 1人2回まで
  • 登録:2005/11/25 10:30:33
  • 終了:--

回答(3件)

id:angelsong No.1

angelsong回答回数94ベストアンサー獲得回数02005/11/25 11:19:26

ポイント25pt

http://www.techscore.com/tech/DesignPattern/index.html

デザインパターン[モデリング] -TECHSCORE-

デザインパターンの話から入った方が分かりやすいでしょうか。それぞれの特徴を簡単に書いてみます。

1.インタフェース

クラスのシグネチャ(メソッド名と引数の型の組み合わせ)のみを定義することで、「振る舞い」のみを利用することが出来る。その中身の実装を知らなくても、使い方だけを覚えれば、コーディングが可能である。(典型は、Iteratorパターンでしょう。配列を対象に、hasNext():まだ次の要素ある?、next():じゃあ、次の要素を取り出すね。と言う使い方だけで、その要素がどんな型であるかは意識しなくても良いですね。)

2.抽象クラス

TemplateMethodパターンが典型ですね。引用したURLの例で言うと、版画を作ると言う行為の手順(メソッドを呼ぶ順序)と材料(属性)は抽象クラス側で定義しておいて、実際に絵を描いたり、木を彫る部分のみサブクラスで実装すれば良い、と言うメリットがあります。抽象クラスを定義することで、類似した処理で同じコーディングを何度も書く必要がなくなりますね。


もし分かりにくい説明でしたら、いわしで補足させてもらいますね。

id:witt

私はデザインパターンを知っているので、

なるほど、こういう視点から説明する方法もあるなぁ、

と新しい気づきを得られた反面、

今回の対象者には敷居が高すぎるのではないかと感じています。

angelsong さまの回答は、至極もっともなんですが、

こう、なんというか、今回の対象者に向けた、スルーパスのような

回答を期待しております。

2005/11/25 22:41:41
id:suke33 No.2

suke33回答回数238ベストアンサー獲得回数32005/11/25 11:44:02

ポイント18pt

クラスが分からない人に3行程度で説明するのはかなり困難だと思います。

せめてクラスと継承について理解してもらってからのほうが良いと思います。

それに「存在意義」ということは、抽象クラスとインターフェイス自体も、概要くらいは知っていないと短文での説明は更に困難だと思います。

とりあえず、クラスぐらいは分かるという前提で書いてみました。でないと、説明内容が多くなってしまうと思います。


上のサイトは説明も分かりやすく、各用語の解説も細かく載っています。このサイトから抜き出した要約例として以下の文章を作ってみました。参考になれば幸いです。


■インターフェイス

インターフェイスとその実装クラスは、スーパークラスとサブクラスの関係とほぼ同じ。実装クラスのインスタンスの参照は、インターフェイスの参照型変数に格納できる。引数として「特定の処理」を行うメソッドを持つインターフェイスを持たせれば、呼び出す側はそのインターフェイスの実装クラスの内、希望の処理を行う「特定の処理」が実装されている実装クラスを渡すことで、メソッド内の処理の一部を「どのように処理するか」呼び出す側が選択することができる。


■抽象クラス

サブクラスの参照をスーパークラスの参照型変数に格納できる機能を使用する場合に、スーパークラスに「一般的な実装」がなく、さらに「必ずサブクラスで実装して欲しい」メソッドがある場合に使用するのがいいだろう。

id:witt

ご紹介いただいた URL 参考になります。

ただ、これらの文法について、仕様上はこうできるという説明に終始しており、

実際に、どういうとき、使えば便利なのかという視点が抜けているように思います。

2005/11/25 22:48:24
id:Kumappus No.3

くまっぷす回答回数3784ベストアンサー獲得回数1852005/11/25 11:54:13

ポイント22pt

http://www.atmarkit.co.jp/fjava/rensai2/javaent14/javaent14.html

@IT:いまから始めるJava 第14回

URLはダミー。

3行でというのは難しいかも、と思いますが

・抽象クラスについて

「空のクラスなんていらないような気がするけど、そこにその子供のクラスが絶対に実装しないといけないものを書いておくと、子供のクラスで実装し忘れがあるとエラーが出るんで間違いが少なくなる」とか。

・インターフェースについて

「あるライブラリを使って実装をする場合に、インターフェースの定義(IDL)だけもらってプログラムをビルドすることができます。APIだと相手が実際にいないとリンクエラーになりますよね。」

あたりではどうでしょうか。


また、VBだとCOM(Active-Xコンポーネントなど)がまさに抽象クラスとインターフェースの応用例なのでそのコンポーネントを作るときに同じインターフェースを持ってるものは例えば表示の色や形などが違うものでもぺたっと張り付ければそのまま使えるでしょ、でもいいかもしれません。

id:witt

> VBだとCOM(Active-Xコンポーネントなど)がまさに抽象クラスとインターフェースの応用例

そういう例があるとイメージしやすいと思います。

私は COM について弱いので、今後、勉強してみます。

2005/11/25 22:57:13
  • id:angelsong
    人に教えるって難しいですね

    デザインパターンをご存じとのこと、釈迦に説法でしたね。失礼致しました。私自身、同様に指導しなくてはならない立場ですので、なかなか悩ましい問題です。
    存在意義は?と問われると3番目のレスにあるように、チョンボをビルドミスと言う形で発見出来ると言う点を除けば、専門家の間でも不要論が交わされる抽象クラスは、具象クラスで十分代用が効くので、いっそ『よっぽどのことがない限り、なくてはならない存在ではないよ』と、ばっさり切り捨てても良いかもしれません。

    インタフェースに関しては、似た性質を持つクラスを一括してキャスト出来るよ、的なニュアンスになるのでしょうか。カプセル化とポリモフィズムと言う本質からは大きくかけ離れた答えになってしまいますが・・・

    と、勝手にJavaを想定して書きましたが、3の方が仰るようにMSが合理的な実装を行っていますね。私もサーバサイドはJavaで、クライアントは.NETで、というスタイルでの開発も担当しています。

    後は、対象となる方が業務屋なのか、フレームワーカーを目指しておられるのかで議論が分かれるでしょうか。
    私見ではありますが、GoFのデザインパターンはあくまで経験則の集合なので、説明用に引用するには便利ですが、『ふーん。だから絶対必要なの?』と問い返されると、なかなか答えに窮してしまいますね。

    興味深い内容でしたので、長々と書いてしまいました。失礼をば。。。

この質問への反応(ブックマークコメント)

「あの人に答えてほしい」「この質問はあの人が答えられそう」というときに、回答リクエストを送ってみてましょう。

これ以上回答リクエストを送信することはできません。制限について

絞り込み :
はてなココの「ともだち」を表示します。
回答リクエストを送信したユーザーはいません