東方算程譚

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とダック・タイピング

ネタ元 → Interfaceが使いこなせない。

interfaceは"責務の集合"に名前(カテゴリ)を与えるものですな。
利用者視点ではその名を冠するものが"~できる"ことが約束されており、
実装者視点ではその名を冠するかぎり"~できる"ことを保証せにゃなりません。
作るひとと使うひとの間の契約とでも申しましょうか。

Java/.NETにはinterfaceがありますけども、C++にはありません。
C++は多重継承があるから、純粋仮想関数だけで構成された
classをinterfaceの代わりに用いたりします。
てゆっかー、多重継承のできないJava/.NETが多重継承のかわりに
用意した、って雰囲気なんですけども。
# Java/.NETはinterfaceならいくつも継承(実装)できますからね

C++ではtemplateを使ったダック・タイピングって手法があります。
"鴨とはなにか"(=interface:鴨は~できる)が明確に定義されてなくたって、
鴨のようにふるまうならそいつぁ鴨とみなしていぃじゃない、
ってリクツです。

#include <iostream>
using namespace std;

// トランプの場札
struct CardDeck {
  void draw() { cout << "カードを一枚引く\n"; }
};

// 預金口座
struct Account {
  void draw() { cout << "預金を引き出す\n"; }
};

// 製図器
struct Drafter {
  void draw() { cout << "図面を描く\n"; }
};

// ...に対し draw する: drawできるならDrawableとみなしていいじゃない
template<typename Drawable>
void draw_by(Drawable& target) {
  target.draw();
}

int main() {
  draw_by(CardDeck());
  draw_by(Account());
  draw_by(Drafter());
}

トランプの場札、預金口座、製図器に共通の基底クラス(=interface)はありません。
が、どれもdrawできるんだからDrawableとみなすわけや。

投稿日時 : 2009年1月27日 9:12

コメントを追加

# re: interfaceとダック・タイピング 2009/01/27 9:21 中博俊

C#4のDynamicでそれっぽいことはできるんだけど、それではないのでつらいところです。

# re: interfaceとダック・タイピング 2009/01/27 9:50 tomma

ありがたいような、ありがたくないような?
経験不足で使う場面をイメージできないので
ヒントくださいな。

# re: interfaceとダック・タイピング 2009/01/27 10:09 774RR

故意にありがたくない例を挙げてんだから、イメージできなくて正解。
# ってこんな例で「実用する場面」のイメージできたら怖いわ・・・

C++ で言えば標準コンテナ+標準アルゴリズムがダックタイピングの典型例っすね
list と vector に共通基底クラスは無い。
でも iterator で次の要素を指示できるとか begin/end があるとか、その辺は同じ
ならば list も vector も *その違いを無視できる範囲であれば* <algorithm> に食わせることができる
逆に
algorithm の1つに食わせることができるようオレオレコンテナを実装できれば、
多分そのコンテナは他の algorithm にも食わせることができる、と。
boost::array なんかがその典型例で。
boost::array のサブセットをワンチップマイコン向けに自作した経験あり。

# re: interfaceとダック・タイピング 2009/01/27 10:10 επιστημη

> 使う場面をイメージできないので

適切かどうか自信ないけど:

template<typename T>
T max(T x, T y) { return x > y ? x : y; }

これも立派なダック・タイピングです。
比較できさえすれば('>'演算できれば)大きいほうが得られます。

# re: interfaceとダック・タイピング 2009/01/27 10:13 επιστημη

> 故意にありがたくない例を挙げてんだから、イメージできなくて正解。

わはは。
「まったくかんけーないのに同じメソッドを持つ」
例を探すのに苦労しました♪

# re: interfaceとダック・タイピング 2009/01/27 10:33 tomma

STLやboostもぎこちなく使ってますが、
その考え方の基本なのですね。
分かってねーなぁ>オレ
有難うさんです。

# re: interfaceとダック・タイピング 2009/01/27 10:57 774RR

俺は template ってのが、そもそもOO的設計に対するアンチテーゼなんだと思うわけよ。
OO的設計=共通部分をあらかじめ分析・設計段階で見つけ出しておき、基底クラスにくくりだす
といえば聞こえはいいけど要するに「*うまく*くくりだすことができなければ失敗」なわけ。
基底クラスの設計失敗ってのは被害がでかい。

template というか、ダックタイピングというか、ようするにジェネリクスだけど
これはアプローチが逆で「わざわざ基底クラスを作らない」ためのやりかた。
だからジェネリクスでは基底クラスを使わないことが多い。
使えば便利な基底クラス binary_function とかも用意されてるけど、
binary_function には実質的な中身は無いし、使わなくてもうまく動く。

C++ はいわゆるOOもジェネリクスも両方使えるし
使わない気になればどちらか/両方使わなくてもいいし
その辺のテキトーさがいいよね。
そういう意味で俺は Ruby とかが好きになれないのだ

# re: interfaceとダック・タイピング 2009/01/27 11:14 p

>binary_function には実質的な中身は無いし、使わなくてもうまく動く。

確か、使わないと動かないのも中にはあるよね
STLの中にはないのかな・・・

# re: interfaceとダック・タイピング 2009/01/27 11:15 επιστημη

> 確か、使わないと動かないのも中にはあるよね

first_argument_type とか result_type とかを
求められるときは必要になるます。トーゼンですが。

# re: interfaceとダック・タイピング 2009/01/27 12:15 774RR

struct mybinaryfunc : binary_function<int, int, bool> { ... };
と書いてOOっぽく派生形式の表記もできるし

struct mybinaryfunc {
typedef int first_argument_type;
typedef bool result_type;
...
}; と書いて
first_argument_type etc, を持っているから binary_function に見える
とダックしてもいいし

どっちゃでも可能ですな。

# C#5に求めるもの 2009/01/27 15:27 中の技術日誌ブログ

C#5に求めるもの

# re: interfaceとダック・タイピング 2009/01/28 10:11 インドリ

やっぱりC++が一番硬派だね。

>てゆっかー、多重継承のできないJava/.NETが多重継承のかわりに
用意した、って雰囲気なんですけども。

本当にそうです。
ちなみにミックスインもそうです。
多重継承はピストルなんで用意されたんです。
でも、C++のようにピストルもある方が嬉しいですね。
C++最高♪

# re: interfaceとダック・タイピング 2009/01/28 10:13 インドリ

おっと忘れていた。
多重継承対策だけではなくて、「実装を継承したくない」時にも使用しましたね。

タイトル
名前
URL
コメント