Python의 functools.singledispatch는 PEP 443에서 도입되었고 Python 3.4에서 출시되어 언어에 일반 함수 기능을 제공했습니다. Clojure와 Julia의 유사한 기능에서 영감을 받아, 개발자가 첫 번째 인자의 타입에 따라 다르게 동작하는 단일 함수 이름을 작성할 수 있도록 합니다. 이는 isinstance() 체인이나 수동 분배 테이블을 사용하는 오랜 패턴을 해결하며, 이는 코드를 복잡하게 만들고 개방/폐쇄 원칙을 위반합니다.
표준화된 분배 메커니즘이 없으면 개발자는 다양한 데이터 타입을 처리하기 위해 함수 내에 임의의 타입 검사를 구현해야 합니다. 이는 코드의 결합도를 높여 새로운 타입을 지원하기 위해 원래 함수의 소스를 수정해야 하고, 확장성을 깨뜨립니다. 또한, 가상 서브클래스와 추상 기본 클래스는 정적 분배 테이블에 도전 과제를 주며, 이는 최적의 일치 구현을 결정하기 위해 런타임 MRO (메서드 해석 순서) 탐색이 필요합니다.
구현은 타입 객체를 해당 핸들러 함수에 매핑하는 내부 _registry 사전을 사용합니다. 일반 함수가 호출될 때, 첫 번째 인자의 타입을 추출하고 조회를 수행합니다. 정확한 타입이 발견되지 않으면, 타입의 MRO를 탐색하여 가장 가까운 등록된 부모 클래스를 찾습니다. register() 메서드는 이 레지스트리를 채우는 데코레이터 팩토리 역할을 합니다. (추상 기본 클래스에서 register()로 등록된) 가상 서브클래스의 경우, 디스패처는 구체적인 타입이 일치하지 않을 경우 등록된 추상 타입에 대해 isinstance()를 확인하여, 상속 없이 다형적 분배를 가능하게 합니다.
from functools import singledispatch from abc import ABC class Shape(ABC): pass class Circle(Shape): def __init__(self, radius): self.radius = radius @singledispatch def area(obj): raise NotImplementedError("지원되지 않는 타입입니다") @area.register(Circle) def _(obj): return 3.14 * obj.radius ** 2 # 가상 서브클래스 지원 @area.register(Shape) def _(obj): return "추상 도형 면적"
여러 소스에서 파일을 수집하는 데이터 처리 파이프라인을 고려해 보세요—JSON, XML, CSV—각각은 서로 다른 파싱 로직을 요구하지만 표준화된 내부 표현을 생성합니다. 초기 구현은 대규모 parse_data(data, file_type) 함수와 isinstance 또는 문자열 식별자를 체크하는 큰 if/elif/else 블록을 사용했습니다. 새로운 형식이 추가됨에 따라 유지 관리가 어려워졌고, 코어 함수의 수정을 필요로 하여 회귀 위험을 초래했습니다.
한 대안 솔루션은 Visitor 패턴으로, 파싱 알고리즘을 데이터 구조와 분리합니다. 이는 개방/폐쇄 원칙을 강제하지만 방문자 클래스를 위한 평행 계층 및 수락 메서드를 생성해야 하여 간단한 타입 기반 분배에 대해 상당한 보일러플레이트를 도입하게 됩니다. 이 패턴은 데이터 구조가 복잡한 객체가 아닌 단순한 문자열 또는 바이트일 때 부자연스럽게 느껴집니다.
고려된 또 다른 접근법은 타입 식별자를 핸들러 함수에 매핑하는 수동 분배 사전입니다. 이는 등록을 구현에서 분리하지만, Python의 타입 시스템과의 통합이 부족합니다. 상속 계층이나 추상 기본 클래스를 자동으로 처리할 수 없으며 개발자는 각 호출 사이트에서 최상의 핸들러를 수동으로 해결해야 하므로 오류가 발생하기 쉽고 반복적입니다.
팀은 functools.singledispatch를 선택했습니다. 이 방법은 자동 MRO 해석 및 깔끔한 데코레이터 기반 등록 구문으로 타입 기반 분배를 1급 지원합니다. 이를 통해 제3자 라이브러리가 코어 라이브러리 코드를 수정하지 않고도 새로운 형식에 대한 파싱 지원을 확장할 수 있습니다. 결과적으로 파싱 모듈의 코드 라인이 40% 감소하고 새로운 형식 핸들러를 추가할 때 병합 충돌이 제거되었습니다. 이제 각 형식은 독립적인 등록 블록에 존재합니다.
정확한 인자 타입이 등록되지 않았을 때 singledispatch가 올바른 구현을 어떻게 해결하며, 메서드 해석 순서(MRO)의 역할은 무엇인가요?
일반 함수가 타입이 레지스트리에 명시적으로 없는 인자를 받으면, 디스패처는 type(obj).__mro__를 사용하여 인자의 클래스 계층을 검사합니다. 객체의 클래스와 부모를 선형화 순서로 나열하는 MRO 튜플을 통해 반복하고, 해당 순서에서 등록된 함수와 관련된 첫 번째 타입을 반환합니다. 이는 부모 클래스에 대해 등록된 핸들러가 그 서브클래스의 인스턴스를 정확히 처리하도록 보장하여 리스코프 치환 원칙 준수를 유지합니다. 전체 MRO를 탐색한 후에도 일치하는 항목이 발견되지 않으면, 디스패처는 일반적으로 NotImplementedError를 발생시키는 @singledispatch로 등록된 원본 함수로 되돌아갑니다.
기존 함수(데코레이터가 아닌) 또는 람다 함수를 singledispatch에 등록할 수 있나요? 등록 해제 구문은 무엇인가요?
예, 기능적 형태를 사용하여 기존 함수를 등록할 수 있습니다: generic_func.register(target_type, existing_function). 이는 다른 곳에서 정의된 함수나 람다로 분배할 때 유용합니다: process.register(int, lambda x: x * 2). 타입을 등록 해제하려면 레지스트리에서 해당 타입에 None을 할당합니다: process.registry[int] = None. 이는 특정 핸들러를 제거하여 이후 해당 타입에 대한 분배가 MRO 검색 또는 기본 구현으로 돌아가게 합니다. 후보자들은 문서에서 데코레이터 구문이 강조되는 반면, 명령형 API는 덜 두드러지기 때문에 종종 이를 놓치게 됩니다.
클래스 내에서 functools.singledispatchmethod가 singledispatch와 어떻게 다르고, 왜 별도의 구현이 필요합니까?
singledispatchmethod는 메서드에 필요합니다. singledispatch는 함수의 첫 번째 인자인 self에 작동하기 때문입니다. 만약 메서드에 singledispatch를 직접 적용하면 인스턴스의 타입에 따라 분배하게 되어 후속 인자의 타입에 따라 작동하지 않습니다. singledispatchmethod는 바인딩 프로세스에서 분배 논리를 분리하기 위해 기술적 프로토콜을 사용합니다: 먼저 self를 바인딩하고, 나머지 인자에 대한 타입 분배를 적용합니다. 이는 self의 타입이 의도한 분배 대상을 방해하지 않도록 하여 메서드가 첫 번째 비자기 인자의 타입에 따라 오버로드될 수 있게 합니다. 이는 C++ 또는 Java가 메서드 오버로딩을 처리하는 방식과 유사합니다.