【Ruby】ダックタイピングって、Nan - Nan ?

ダックタイピングとは?

"If it walks like a duck and quacks like a duck, it must be a duck"
(もしもそれがアヒルのように歩き、アヒルのように鳴くのなら、それはアヒルに違いない)

 

意訳

 

「オブジェクトがアヒルのように歩き、アヒルのように鳴くメソッドを実装しているなら、そのオブジェクトのクラスが何であれ、アヒルと同じ役割を果たせる」と言えるかと思います。
「そのオブジェクトのクラスが何であれ」という表現をしたように、ダックタイピングとは、どんな特定のクラスとも紐付かないインタフェースを定義することです。

 

参考

qiita.com

 

 

いきなり結論

madogiwa0124.hatenablog.com

 

紹介されていらっしゃる技術書の例題を使用しての説明です。

とても分かりやすいですね。感謝いたします。

 

def clean などそれぞれのクラスに個別に定義されているメソッドを、改修のたびに確認追加は手間なので、work というメソッドを用意することで、

そのクラスに実行させたいことをwork→cleanと実装することで、

仮にwork後の仕様変更に伴う改修が行われても、workメソッドのみを改修で済みます。

また例では、実行したい処理(work)でメソッド名統一もでき、

このメソッドがwork(ダック・タイピングで言うところの、鳴くこと)ということだけ分かればよい、という思想での設計でできます。

 

メリット・デメリット

メリット:

 

下記はメンターの方のアドバイスより。

型が間違っていてもメソッドを持っていれば動くというのは

「ダックタイピング」と呼ばれるのですが、これはこれで便利な場合もあります。

 

オブジェクト指向ポリモーフィズムと呼ばれる手法を用いる場合に、

型がある言語だとInterfaceを別途定義する必要があるのですが、

Rubyの場合はメソッド名を合わせるだけで実現ができます。

 

これはRubyが「楽しくプログラミングできる言語である」と呼ばれる所以だと思っています。

 

 

デメリット:

同じくメンターの方から

 

型がないから間違ったクラスのオブジェクトを渡してしまう可能性があるのは確かで、Ruby3以降だと型を扱えるようにする動きも出てきていますね。(RBS)

オーバーロード時に疑問に思った点でした。

 

また下記の様な考察・言及もありました。

 

zenn.dev

 

この文章中のサンプルコードが分かりやすいものでした。

ああ、これでも実行できちゃうのか!と驚きました。

ダックタイピングの自由さによる弊害は、こういったクラス間でよく起こる問題なのかもしれません。

 

そして大規模案件でRubyが広く使用されない点、

確かに受託や自社開発で請け負っていて一貫したコーディング(規則・技術レベル)が保てるなら問題ないのでしょうが、

SES・SIerを見るとたくさんの会社から多種多様な契約で様々な契約期間にバラエティーに飛んだコーディングを行うので・・・Javaみたく縛れる言語はある種、最適なんでしょうね。。。

 

ただし、

それを補う魅力があることによって今日までRubyistの方々に愛され、普及したのでしょう。

そして間違いなくその点を解消できる設計や実装方法はあるかと思いますので、

これから学んでいけたらと思います。