답변.

덕 타이핑은 객체가 클래스 계층구조에 속하기보다 그 행동에 따라 다루어지는 파이썬의 기본 원칙입니다.

질문의 역사

이 용어는 "무언가가 오리처럼 보이고, 오리처럼 헤엄치고, 오리처럼 꽥꽥거린다면 — 그건 오리다"라는 속담에서 유래됩니다. 파이썬에서 객체의 행동(인터페이스)은 그 객체가 속한 클래스보다 더 중요합니다. 이는 "덕 타이핑" - 행동에 의한 타입화(구조적 타입화)를 구현합니다.

문제

덕 타이핑이 최대한의 유연성을 제공하는 것처럼 보입니다. 하지만 이는 숨겨진 버그의 수를 증가시킵니다: 프로그램은 객체가 필요한 인터페이스를 지원하지 않을 때만 실행 중에 "엉망이" 됩니다.

해결책

타입 검사 대신 (isinstance 또는 type을 통해) 객체에서 필요한 메서드를 호출하려고 시도하는 함수를 작성하세요. 만약 그 객체가 그것을 지원한다면 — 모든 것이 작동할 것입니다. 최악의 경우 AttributeError 또는 TypeError를 잡아내어 예상치 못한 객체를 처리하세요.

예시:

def quack_and_walk(duck):
    duck.quack()
    duck.walk()

class Robot:
    def quack(self):
        print("나는 꽥꽥거릴 수 있어!")
    def walk(self):
        print("나는 걷고 있어")

quack_and_walk(Robot())  # 모든 것이 작동할 것입니다!

핵심 특징:

객체의 행동이 그 클래스보다 중요합니다.
필요한 메서드를 구현하면 상속 없이 완전히 새로운 타입의 코드를 사용할 수 있습니다.
단점: 누락된 메서드로 인한 오류는 실행 중에만 발생합니다.

함정 질문들.

파이썬에서 isinstance를 통해 타입을 확인하고 덕 타이핑에 대해 올바르다고 말할 수 있을까요?

아니요. 덕 타이핑은 정확히 강력한 타입 검사를 반대합니다. 객체의 행동을 다루는 것이 그 계보를 다루는 것보다 더 적절합니다.

추상 기본 클래스를 통해 덕 타이핑을 구현할 수 있을까요?

부분적으로. 추상 클래스는 정적 구조 요소를 도입합니다. 덕 타이핑은 관계를 선언할 필요가 없습니다 - 필요한 메서드를 단순히 구현하면 됩니다. 하지만 파이썬 3.8부터 typing.Protocol 모듈이 도입되어 구조적 타입화에 더 가까워졌습니다.

덕 타이핑이 매직 메서드(len, getitem 등)와 함께 작동할 수 있나요?

예. 만약 객체가 필요한 메서드(len)를 구현하고 있다면, 해당 객체를 len(obj)와 같은 함수에 전달할 수 있으며, 이는 덕 타이핑에 따라 작동합니다.

일반적인 오류 및 안티 패턴

행동이 아닌 클래스 기반 검사(isinstance)에 의존하기.
메서드가 없을 경우 발생할 수 있는 예외를 처리하지 않기.
명확한 타입 보장이 필요한 곳에서 덕 타이핑을 사용하기 (예: 중요한 라이브러리에서).

실생활 예시

부정적인 사례

개발자가 확인 없이 메서드를 run()으로 받는 함수를 작성합니다. 코드에 이 메서드가 없는 객체가 등장하고 — 오류는 런타임에서만 발생합니다.

장점:

유연성, 빠른 프로토타이핑.

단점:

디버깅하기 어려움, 오류의 높은 비용 (예상치 못한 위치에서 프로그램이 중단됨).

긍정적인 사례

덕 타이핑을 사용하되 try/except 및 인터페이스 문서화를 사용합니다:

def run_task(obj):
    try:
        obj.run()
    except AttributeError:
        print("객체가 작업 실행을 지원하지 않습니다!")