東方算程譚

Oriental Code Talk ── επιστημηが与太をこく、弾幕とは無縁のシロモノ。

目次

Blog 利用状況

ニュース

著作とお薦めの品々は

著作とお薦めの品々は
東方熱帯林へ。

あわせて読みたい

わんくま

  1. 東京勉強会#2
    C++/CLI カクテル・レシピ
  2. 東京勉強会#3
    template vs. generics
  3. 大阪勉強会#6
    C++むかしばなし
  4. 東京勉強会#7
    C++むかしばなし
  5. 東京勉強会#8
    STL/CLRによるGeneric Programming
  6. TechEd 2007 @YOKOHAMA
    C++・C++/CLI・C# 適材適所
  7. 東京勉強会#14
    Making of BOF
  8. 東京勉強会#15
    状態遷移
  9. 名古屋勉強会#2
    WinUnit - お気楽お手軽UnitTest

CodeZine

  1. Cで実現する「ぷちオブジェクト指向」
  2. CUnitによるテスト駆動開発
  3. SQLiteで組み込みDB体験(2007年版)
  4. C++/CLIによるCライブラリの.NET化
  5. C# 1.1からC# 3.0まで~言語仕様の進化
  6. BoostでC++0xのライブラリ「TR1」を先取りしよう (1)
  7. BoostでC++0xのライブラリ「TR1」を先取りしよう (2)
  8. BoostでC++0xのライブラリ「TR1」を先取りしよう (3)
  9. BoostでC++0xのライブラリ「TR1」を先取りしよう (4)
  10. BoostでC++0xのライブラリ「TR1」を先取りしよう (5)
  11. C/C++に対応した、もうひとつのUnitTestFramework ─ WinUnit
  12. SQLiteで"おこづかいちょう"
  13. STL/CLRツアーガイド
  14. マージ・ソート : 巨大データのソート法
  15. ヒープソートのアルゴリズム
  16. C++0xの新機能「ラムダ式」を次期Visual Studioでいち早く試す
  17. .NETでマンデルブロ集合を描く
  18. .NETでマンデルブロ集合を描く(後日談)
  19. C++/CLI : とある文字列の相互変換(コンバージョン)
  20. インテルTBBによる選択ソートの高速化
  21. インテルTBB3.0 によるパイプライン処理
  22. Visual C++ 2010に追加されたSTLアルゴリズム
  23. Visual C++ 2010に追加されたSTLコンテナ「forward_list」
  24. shared_ptrによるObserverパターンの実装
  25. .NETでマンデルブロ集合を描く(番外編) ── OpenCLで超並列コンピューティング
  26. StateパターンでCSVを読む
  27. 状態遷移表からStateパターンを自動生成する
  28. 「ソートも、サーチも、あるんだよ」~標準C++ライブラリにみるアルゴリズムの面白さ
  29. インテルTBBの同期メカニズム
  30. なぜsetを使っちゃいけないの?
  31. WPFアプリケーションで腕試し ~C++でもWPFアプリを
  32. C++11 : スレッド・ライブラリひとめぐり
  33. Google製のC++ Unit Test Framework「Google Test」を使ってみる
  34. メールでデータベースを更新するココロミ
  35. Visitorパターンで遊んでみたよ
  36. Collection 2題:「WPFにバインドできる辞書」と「重複を許す検索set」
  37. Visual C++ 2012:stateless-lambdaとSQLiteのぷち拡張
  38. 「Visual C++ Compiler November 2012 CTP」で追加された6つの新機能

@IT

  1. Vista時代のVisual C++の流儀(前編)Vista到来。既存C/C++資産の.NET化を始めよう!
  2. Vista時代のVisual C++の流儀(中編)MFCから.NETへの実践的移行計画
  3. Vista時代のVisual C++の流儀(後編) STL/CLRによるDocument/Viewアーキテクチャ
  4. C++開発者のための単体テスト入門 第1回 C++開発者の皆さん。テスト、ちゃんとしていますか?
  5. C++開発者のための単体テスト入門 第2回 C++アプリケーションの効率的なテスト手法(CppUnit編)
  6. C++開発者のための単体テスト入門 第3回 C++アプリケーションの効率的なテスト手法(NUnit編)

AWARDS


Microsoft MVP
for Visual Developer - Visual C++


Wankuma MVP
for いぢわる C++


Nyantora MVP
for こくまろ中国茶

Xbox

Links

記事カテゴリ

書庫

日記カテゴリ

それでいいんですかぃ?

某所にて
「インターフェースに対して拡張メソッドでメソッドを追加するようにすれば、
事実上多重継承が実現できます」

ってゆーてた。えー、どゆことソレ? って突っ込んでみたところ:

  interface Iほげらぶる {};

  static class ほげらぶる実装 {
    public static void ほげ(this Iほげらぶる hoge) {
      Console.WriteLine("ほげほげー");
    }
  }

  interface Iぱよらぶる {};

  static class ぱよらぶる実装 {
    public static void ぱよ(this Iぱよらぶる payo) {
      Console.WriteLine("ぱよぱよー");
    }
  }

  class ぺも : Iほげらぶる, Iぱよらぶる {
    public static void Main() {
      ぺも p = new ぺも();
      p.ほげ();
      p.ぱよ();
    }
  }

なるほど、拡張メソッドによってインタフェースに実装を貼り付けることが
できるんだから、実装の貼り付いたインタフェースを多重継承すれば双方の
実装を継承できるってわけか。

でもねー、シグニチャがカブったらどないすんのよ。

  interface IMachine {};

  static class MachineImpl {
    public static void move(this IMachine machine) {
      Console.WriteLine("計算機がモーターを制御します");
    }
  }

  interface IHuman {};

  static class HumanImpl {
    public static void move(this IHuman human) {
      Console.WriteLine("神経系が筋肉を制御します");
    }
  }

  class Android : IMachine, IHuman {
    public void move() {
      Console.WriteLine("ギコギコ歩きますー");
    }
    public static void Main() {
      Android RTI = new Android();
      RTI.move();
    }
  }

Androidmoveを再定義できるから破綻は免れたけども...
これでも多重継承できたというてえぇのやろうか。意見求ム。

投稿日時 : 2008年7月30日 6:29

コメントを追加

# re: それでいいんですかぃ? 2008/07/30 9:01 ネタ好き未記入

オブジェクト指向の根源をメッセージ通信として捉えたら、委譲と考えられるのでぎりぎりセーフだと思います。それに、明示的に指定するのは多重継承も条件は同じだと思います。
でも、C++と同じ水準のオーバーライドが出来ないのは痛いので多重継承と等価とはいえないと思います。

# re: それでいいんですかぃ? 2008/07/30 9:17 ネタ好き未記入

今思ったのですが、明示的宣言についてもちょっと両者は違いますね。C++には仮想基本クラスがあるから、継承関係の動作も異なると思います。

# re: それでいいんですかぃ? 2008/07/30 9:29 ネタ好き未記入

色々細かい差異はまだあると思いますが、個人的な意見を書くと、これは【委譲であって多重継承ではない】と思います。

# re: それでいいんですかぃ? 2008/07/30 9:30 シャノン

ははァ、これは面白いですな。
ところで RTI ってのは R・田中一郎の略でしょうか?
彼はギコギコ歩くんでしょうか。

# re: それでいいんですかぃ? 2008/07/30 9:41 επιστημη

ギコギコ歩いてるならまだマシで、
腰痛めて動けなくなってたりします。
ご自愛めされい。

# re: それでいいんですかぃ? 2008/07/30 9:54 oki

Java畑の人にとっては、正当な考え方…つか、継承よりも Interface を使おうってぐらいだし、多重継承でけへんし…。
COM的に考えれば、集約か委譲って事に…。被ってる部分の挙動は、考え方次第でしょうけど、どうすんだろ…。
使い方が、欲しいInterface を取り出してからのご利用となっております~、アー、君・君、IMachine しか私は受付しませんよ…って、設計のライブラリになるのかな~。

# re: それでいいんですかぃ? 2008/07/30 10:21 R・田中一郎

知らないところでネタにされてる~w

そもそも、インターフェイスは継承すると表現しますし、複数のインターフェイスを継承したら、一応は多重継承と呼んでも間違いではない気がします。

しかし、この方法は面白いです。
今度、評価的に使ってみようと思います。

# re: それでいいんですかぃ? 2008/07/30 10:22 シャノン

> インターフェイスは継承すると表現しますし

実装すると表現する方が多い気がします。

# re: それでいいんですかぃ? 2008/07/30 11:47 επιστημη

interface IAndroid : IMachine, IHuman {};

ならインターフェイスの"多重継承"ってゆーのかな。
実装してないしー。

class Android : IMachine, IHuman {
public void move() { ... }
}

だと多重実装? あんのかそんな用語?

# re: それでいいんですかぃ? 2008/07/30 18:37 oki

google さまに "polymorphic implementation" で伺ってみますた…あるみたいですね?。
型安全性と分離性について…とか、それっぽい事書いてある…

# re: それでいいんですかぃ? 2008/07/30 19:41 R・田中一郎

今、試しに使ってみようと思ったんですけど、これって本当に使っちゃって大丈夫なのか心配になってきました。

インターフェイスに拡張メソッドで実装なんて、どうも釈然としないというか、これってできるからといってやって良いことなのかな~?

# re: それでいいんですかぃ? 2008/07/30 19:54 επιστημη

> インターフェイスに拡張メソッドで実装

LINQなんかまさにコレぢゃん♪

タイトル
名前
URL
コメント