ダック・タイピング
ダック・タイピング(duck typing)とは、Smalltalk、Perl、PHP、Python、Ruby、JavaScriptなどの動的型付けに対応したオブジェクト指向プログラミング言語に特徴的な、型付けのスタイル(作法)のひとつである。ダック・タイピングはポリモーフィズム(多態性)を実現する手段のひとつとして使われる。
Pythonのリファレンスでは、ダック・タイピングは「あるオブジェクトが正しいインタフェースを持っているかどうかを決定するために、オブジェクトの型を見ることはしないプログラミングスタイルである」と説明されている。代わりに、オブジェクトが持つメソッドや属性(フィールドまたはプロパティ)が単純に呼ばれたり使われたりする。特定の型よりもインタフェースを重視することで、うまく設計されたコードは、ポリモーフィックな代入の許可による柔軟性を向上する。
静的型付け言語では型検査をコンパイル時に実施する一方、動的型付け言語では型検査を実行時に実施する。つまり、動的型付けでは、オブジェクト(変数の値)に何ができるか(どのようなインタフェースを持っているか)は、実行時のオブジェクトそのものが決定する。
ダック・タイピングについて、継承機能によるサブタイプ(部分型)多相 (subtype polymorphism) を主に用いる静的型付けのオブジェクト指向言語であるJavaやC#の概念で例えると、オブジェクトがあるインタフェースのすべてのメソッドを持っているならば、たとえそのクラスがそのインタフェースを宣言的に実装していなくとも、オブジェクトはそのインタフェースを実行時に実装しているとみなせる、ということである。それはまた、同じインタフェースを実装するオブジェクト同士が、それぞれがどのような継承階層を持っているのかということと無関係に、相互に交換可能であるという意味でもある。ダック・タイピングは構造的型付け (structural typing) に類似しており、構造的型付けの多態性(多相性)はロー多相 (row polymorphism) に分類されることがある(日本語では行多相あるいは列多相とも)。構造的型付けは名前的型付け (nominal typing / nominative typing) nominalは公称的、名目的または記名的とも訳される。と対比される型システムの分類のひとつである。
この用語の名前は「ダック・テスト」に由来する。
"If it walks like a duck and quacks like a duck, it must be a duck"(もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルに違いない)
C++のテンプレートはダック・タイピングの静的版である。例えば、STLにおける各種のiteratorはIterator基底クラスのようなものからメソッドを継承しているわけではないが、特定の演算子を利用できて同じ構文でコンパイルが通るならば、それはiteratorの一種として扱える。この文脈で言う「同じインタフェースを持つ」とは、コンパイラにとってシグネチャなどのインタフェースが同じだということである。したがって、iteratorの実装はオブジェクトである必要すらない。
もう1つ、ダック・タイピングに似たアプローチにOCamlの構造的サブタイピング (structural subtyping) があるtypingは「型付け」と訳されることが多いが、subclassingは「サブクラス化」と訳されることが多い。subtypingは「部分型付け」や「サブタイプ化」としてもよいかもしれないが、本記事ではduck typingを「ダック・タイピング」とカナ表記しているのでそれに準じることにする。。メソッドのシグネチャが互換ならば、宣言上の継承関係はなくとも、オブジェクトの型は互換であるというものである。これはOCamlの型推論システムによってコンパイル時にすべて決定される(コンパイラによる静的な型検査を受ける)。TypeScriptの型互換性も構造的サブタイピングに基づいている。対義語は名前的サブタイピング (nominal subtyping) であり、例えばJavaやC#などの継承ベースの型システムで用いられている方式のことである。
PythonやRubyは一般的なクラス継承の機能も持っており、継承によるポリモーフィズムも利用できるが、ダック・タイピングによるポリモーフィズムは継承が不要であり、型による制約に縛られることなく簡素なコードで実現できる点にメリットがある。しかし、制約がないということは乱用しやすいということの裏返しでもある。型制約がない場合はコンパイラによる静的な型検査や統合開発環境 (IDE) によるコード補完などの支援が見込めず、プログラムの記述ミスを発見するのが難しくなることもある。Pythonのダック・タイピングでは、オブジェクトが特定の属性を実際に持っているかどうかをhasattr()で事前チェックしたり、例外処理を記述したりする方法が採られる。Pythonはダック・タイピングを補完するために抽象基底クラスの機能を導入した。
Rubyでの単純な例を示す。
出力は以下である。
2つのクラスに継承の関係が無いことに注目して欲しい。上記のtestメソッドは、soundという名前のメンバーを持つオブジェクトであれば何でも受け付ける。なお、Rubyのputsは引数オブジェクトを自動的に文字列に変換して標準出力に出力するため、仮に文字列以外を返すsoundであっても受け付ける。このような柔軟性が動的言語の特徴である。
上記Rubyの例をC++で記述すると、以下のようになる。
実行結果はRubyの例と同じである。ただし、テンプレートによるダック・タイピングはコンパイル時に解決される静的なポリモーフィズム (static polymorphism) であり、動的型付け言語とは異なり実行時のオーバーヘッドを伴わない。
C#はバージョン4.0で動的型付けを可能にするdynamic型が使えるようになった。dynamicは内部的にはリフレクションを利用して実装されており、該当するメソッドやプロパティの存在有無を実行時に遅延評価する。シンボル解決に失敗した場合は例外がスローされる。
なお、C#はC++のテンプレートに似た機能としてジェネリクスをサポートするが、C++テンプレートほどの柔軟性はなく、ダック・タイピングに使用することはできない。
Visual Basic .NET (VB.NET) はOption Strict Offが指定されている場合、System.Object型による遅延バインディング (late binding) ができるようになり、これによりダック・タイピングをサポートできる。これは、VB.NETが登場当初から従来のVisual BasicおよびVisual Basic for Applications (VBA) からの移行を狙っていたため、ゆるい型付けをサポートする必要があったことに由来する。
下記の例は、Option Strict Onを指定すると静的な型チェックが有効になり、コンパイルエラーになる。
Javaは言語構文レベルで動的型付けをサポートしないが、リフレクションを用いることで、ダック・タイピング相当を実現できる。Core Reflection APIとして、java.lang.reflectパッケージが用意されている。また、Java Native Interface (JNI) を用いることで、C言語やC++などのネイティブコードからJavaで書かれたクラスを利用することができるが、リフレクション同様にダック・タイピングに応用することもできる。
COMにおいても、IDispatchインタフェースを実装することで、ダック・タイピング相当を実現できる。VBScriptやJScriptといったスクリプト言語(動的プログラミング言語)の実装を容易にするための基盤として、拡張インタフェースIDispatchExも用意されている。