duck typing은 객체의 적합성이 클래스나 타입이 아니라 어떤 메서드에 응답하는지로 결정되는 원칙입니다 — "오리처럼 걷고 오리처럼 꽥꽥거리면, 그것은 오리다." Ruby에서는 객체가 어떤 타입인지가 아니라 무언가를 할 수 있는지(메서드를 가졌는지)에 신경 씁니다. 이는 상속이나 인터페이스 없이 유연하고 다형적인 코드를 가능하게 합니다.
()
duck.quack
=
=
make_it_quack(.new)
make_it_quack(.new)
make_it_quack은 quack 메서드를 가진 모든 객체와 동작합니다 — Duck, Person, 무엇이든. 타입을 검사하지 않고 그저 메서드를 호출합니다. 이는 공유 상속이나 명시적 인터페이스 없는 다형성입니다.
# Ruby 코드는 일반적으로 타입 검사가 아닌 메서드 존재에 의존함
def process(items)
items.each { |i| puts i } # `each`를 가진 모든 객체와 동작
# → 배열, Set, 범위, 커스텀 Enumerable... 모두 each로 "꽥꽥"
end
# << 연산자: 이를 정의하는 모든 것에서 동작
def append_to(collection, item)
collection << item # 배열, 문자열, IO, Logger... 모두 <<를 가짐
end
# ✅ duck-typed — 메서드에 응답하는지 확인 (동작)
if obj.respond_to?(:each)
obj.each { ... }
end
# ❌ 덜 Ruby다움 — 클래스/타입 확인
if obj.is_a?(Array) # 경직됨; duck typing은 역량 확인을 선호
end
관용적인 Ruby는 유연성이 중요할 때 is_a?(이 타입인가?)보다 respond_to?(이 메서드를 가졌는가?)를 사용합니다 — 클래스가 아닌 역량에 초점을 맞춥니다.
duck typing은 근본적인 Ruby 원칙이자 Ruby가 유연성과 다형성을 이루는 방식의 정의적 특성이므로, 이를 이해하는 것은 관용적인 Ruby를 작성하는 데 중요합니다.
핵심 아이디어 — 객체의 적합성이 **클래스/타입이 아니라 무엇을 할 수 있는지(그 메서드)**로 결정된다는 것 — 은 공유 상속이나 명시적 인터페이스를 요구하지 않고 유연하고 다형적인 코드를 가능하게 합니다(다형성에 공통 기반 클래스나 인터페이스가 필요한 정적 타입 언어와 달리).
이는 해방적이고 강력합니다: 메서드가 필요한 메서드에 응답하는 모든 객체와 동작하므로, "꽥꽥거리는" 무엇이든 — 다른 클래스, 커스텀 객체 — 전달할 수 있고 그냥 동작하여, 코드를 재사용 가능하고 적응력 있게 만듭니다.
duck typing을 이해하면 Ruby의 유연하고 동작 중심적인 스타일과, Ruby 코드가 일반적으로 타입 검사(is_a?)보다 메서드 존재(respond_to?)에 의존하는 이유가 설명됩니다 — 클래스보다 역량에 초점을 맞추는 것이 관용적인 Ruby 접근법입니다.
이 원칙은 Ruby의 우아함과 그 라이브러리·프레임워크의 유연성(올바른 메서드를 제공하는 무엇과도 동작함, 예: each나 <<를 가진 무엇이든)의 상당 부분을 떠받칩니다.
duck typing을 파악하는 것 — Ruby가 타입이 아닌 동작에 신경 쓴다는 것, 인터페이스 없는 다형성을 가능하게 한다는 것, 관용적인 Ruby가 클래스가 아닌 역량을 확인한다는 것 — 은 유연하고 관용적인 Ruby를 작성하고, 정적 타입 언어와 Ruby를 구별하는 동적이고 동작 지향적인 철학을 이해하는 데 중요합니다.
이는 Ruby의 유연한 설계를 담아내는 핵심 개념 주제이자 동적인 duck-typed 프로그래밍에 대한 이해를 반영하는 빈번한 면접 지점입니다.
주니어부터 시니어까지 상세한 답변이 포함된 IT 면접 질문 라이브러리.
후원하기