ダックタイピングの紹介
お久しぶりです。とりかつです。最近は設計とかアーキテクチャとかOOPとかを学習しているのですが、そのなかで「ダックタイピング」というものが出てきました。
はじめに
お久しぶりです。とりかつです。
最近は設計とかアーキテクチャとかOOPとかを学習しているのですが、そのなかで「ダックタイピング」というものが出てきました。今回の記事ではその紹介とそれについて思ったことを簡単に書いていこうと思います。
一応なんですけど、自分は静的型付け言語触ってきたこともあり、若干偏見が混じってるかもしれません。ご了承ください。
ダックタピングとは
うまく説明できる自信がないので具体例をあげながら説明します。
犬を表すDogクラスと、猫を表すCatクラスがあります。
犬と猫はそれぞれ吠えたり鳴いたりするメソッドを持っています。
class Cat
def meow
"にゃー"
end
end
class Dog
def bow
"わん"
end
end
class Main
dog = Dog.new
cat = Cat.new
# なかせる
# わん
dog.bow
#にゃー
cat.meow
end
で、ここからがダックタイピングなんですけども、犬も猫も鳴き声は違えど、とりあえず鳴きますよね。
犬も猫も鳴き声ごとに呼び出すメソッドを変えるんじゃなくて、どっちにも「鳴いて!」って言えば鳴いてくれた方がクラス間の依存を疎結合に保つことができそうですよね。 ということで上のコードをダックタイピングで書き換えてみました。
class Cat
# パブリックインターフェース
def cry
meow
end
def meow
"にゃー"
end
end
class Dog
def cry
bow
end
def bow
"わん"
end
end
class Main
dog = Dog.new
cat = Cat.new
# なかせる
# わん
dog.cry
#にゃー
cat.cry
end
DogクラスもCatクラスも固有の鳴き声メソッドをcryメソッドでラップしてあげることでどちらも同じメソッドを呼び出すだけで鳴かせることができるようになりました。これがダックタイピングです。
ダックタイピングの利点
ダックタイピングの利点として以下が挙げられると思います。
- 型を判別して呼び出すメソッドを分岐させる必要がないということは依存性を減らせる
- 明示的にインターフェースを実装する必要がない
もちろん他にも利点はあると思いますが自分の認識では上の2つが大きい利点だと考えています。
静的型付け言語のinterfaceつかえばよくない?
javaとか静的型付け言語触ってきた人はここであれ?と思っていると思います。
わざわざ暗黙的にインターフェースを実装しなくてもinterface使えば良さそうですよね。インターフェースの実装が強制されていること知らないチームメンバーがいたら…なんてケースも考えられます。
もちろんその考え方も間違ってないと思います。でもそれは静的型付け言語に慣れてきたからこその感覚だと思います。
そもそも静的型付け言語は「こんなインターフェース用意してるから使って!」ってイメージで、動的型付け言語は「とりあえずこのインターフェース呼べば良さそう!なかったらその時考えよう」ってイメージです(偏見)。
なのでどっちが優れてるとかじゃなくてどっちにもメリットとデメリットはあるよってことだと思います。
毒だって使い方によっては薬になりますよね。今回紹介しているテクニックもそれと同じで適しているところに使えば大きなメリットを生みますし、変な使い方をすれば大きくコストをかけることになったりもします。
ちなみに先ほどの
インターフェースの実装が強制されていること知らないチームメンバーがいたら…
の解決策としてテストで実装を強制することが挙げられます。
まとめ
今回はダックタイピングについて紹介しました。個人的には動的型付け言語ならではの面白いテクニックだなと感じました。Railsとかで開発する際に積極的に使ってみたいです。
-––