make_it_quackは、quackメソッドを持つあらゆるオブジェクト——Duck、Person、何でも——で動作します。型をチェックせず、ただメソッドを呼ぶだけです。これは共有された継承や明示的なインターフェースなしのポリモーフィズムです。
# Ruby code typically relies on method presence, not type checks
def process(items)
items.each { |i| puts i } # works with ANY object that has `each`
# → an Array, a Set, a Range, a custom Enumerable... all "quack" with each
end
# the << operator: works on anything that defines it
def append_to(collection, item)
collection << item # works on Array, String, IO, Logger... they all have <<
end
# ✅ duck-typed — check if it responds to a method (behavior)
if obj.respond_to?(:each)
obj.each { ... }
end
# ❌ less Ruby-like — checking the class/type
if obj.is_a?(Array) # rigid; duck typing prefers checking capability
end
慣用的なRubyは、柔軟性が重要な場合、is_a?（これはこの型か？）よりもrespond_to?（このメソッドを持つか？）を使い、クラスではなく能力に焦点を当てます。
ダックタイピングはRubyの基本原則であり、Rubyが柔軟性とポリモーフィズムをどう実現するかを特徴づけるものなので、これを理解することは慣用的なRubyを書くうえで重要です。
中心的な考え方——オブジェクトの適合性は、そのクラス／型ではなく**何ができるか（そのメソッド）**で判断される——は、共有された継承や明示的なインターフェースを必要とせずに（ポリモーフィズムに共通の基底クラスやインターフェースが必要な静的型付け言語とは異なり）柔軟でポリモーフィックなコードを可能にします。
これは解放的で強力です。メソッドは必要なメソッドに応答するあらゆるオブジェクトで動作するため、「鳴く」ものなら何でも——異なるクラス、カスタムオブジェクト——渡せて、ただ動作します。これによりコードは再利用可能で適応性のあるものになります。
ダックタイピングを理解することは、Rubyの柔軟で振る舞い重視のスタイルを説明し、Rubyコードがなぜ典型的に型チェック（is_a?）ではなくメソッドの存在（respond_to?）に依存するか——クラスより能力に焦点を当てることが慣用的なRubyの流儀である——を説明します。
この原則は、Rubyの優雅さの多くと、そのライブラリやフレームワークの柔軟性（eachや<<を持つものなら何でも動作するように、正しいメソッドを提供するものなら何でも動作する）を支えています。
ダックタイピングを把握すること——Rubyは型ではなく振る舞いを気にし、インターフェース不要のポリモーフィズムを可能にし、慣用的なRubyはクラスではなく能力をチェックする——は、柔軟で慣用的なRubyを書くため、そしてRubyを静的型付け言語と区別する動的で振る舞い指向の哲学を理解するために重要です。
これはRubyの柔軟な設計を捉える中核的な概念的テーマであり、動的でダックタイピングのプログラミングへの理解を反映する面接の頻出ポイントです。