저자는 두 개의 서로 다른 이미지 생성 백엔드와 상호 작용하는 CLI 도구를 위한 공유 계약을 설계하고 있었습니다. 목표는 CLI가 일반적인 submit(request) 함수를 사용할 수 있도록 하고, 각 백엔드는 이를 자체 SDK 호출로 변환하는 것이었습니다. 처음에는 저자가 추상 메서드를 강제하기 때문에 공유 인터페이스로 추상 기본 클래스(ABC)를 고려했습니다. 그러나 ABC는 상속이 필요하며, 이는 타사 플러그인 가능한 백엔드에 대한 결합을 생성합니다.typing.Protocol은 구조적 타이핑을 사용하기 때문에 더 나은 선택으로 부상했습니다. 클래스는 명시적인 상속을 요구하지 않고 올바른 시그니처를 가진 올바른 메서드를 가짐으로써 프로토콜을 만족합니다. 이 접근 방식은 외부 구현자를 핵심 패키지에서 분리하여 제공자가 독립적으로 발전할 수 있도록 합니다. 프로토콜은 제공자가 엄격한 계층 구조의 일부가 아니라 값으로 전달되는 구성 기반 디자인을 촉진합니다.프로토콜은 플러그인 경계를 설명하는 데 이상적이지만, 제공자가 구체적인 동작이나 구현 로직을 공유해야 할 때는 ABC가 더 적합합니다. ABC는 공유 메서드를 정의하고 구체적인 하위 클래스가 구현해야 하는 추상 메서드를 강제할 수 있습니다. 둘 다 사용하는 것도 가능합니다. 즉, 공개 플러그인 경계를 위한 프로토콜과 제공자 간의 공유 동작을 위한 내부 ABC입니다.저자는 더 가벼운 계약을 위해 프로토콜을 기본값으로 사용하고, 공유 구현이 필요하거나 추상 메서드의 런타임 강제가 필요할 때만 ABC로 전환할 것을 권장합니다. 플러그인 생태계의 경우, "상속으로 준수" (ABC)보다 "모양으로 준수" (프로토콜)가 종종 선호됩니다. 선택은 기본 요구 사항이 모양을 정의하는 것인지, 아니면 구체적인 동작을 공유하고 계층 구조를 강제하는 것인지에 따라 달라집니다.
submit(request)함수를 사용할 수 있도록 하고, 각 백엔드는 이를 자체 SDK 호출로 변환하는 것이었습니다. 처음에는 저자가 추상 메서드를 강제하기 때문에 공유 인터페이스로 추상 기본 클래스(ABC)를 고려했습니다. 그러나 ABC는 상속이 필요하며, 이는 타사 플러그인 가능한 백엔드에 대한 결합을 생성합니다.typing.Protocol은 구조적 타이핑을 사용하기 때문에 더 나은 선택으로 부상했습니다. 클래스는 명시적인 상속을 요구하지 않고 올바른 시그니처를 가진 올바른 메서드를 가짐으로써 프로토콜을 만족합니다. 이 접근 방식은 외부 구현자를 핵심 패키지에서 분리하여 제공자가 독립적으로 발전할 수 있도록 합니다. 프로토콜은 제공자가 엄격한 계층 구조의 일부가 아니라 값으로 전달되는 구성 기반 디자인을 촉진합니다.프로토콜은 플러그인 경계를 설명하는 데 이상적이지만, 제공자가 구체적인 동작이나 구현 로직을 공유해야 할 때는 ABC가 더 적합합니다. ABC는 공유 메서드를 정의하고 구체적인 하위 클래스가 구현해야 하는 추상 메서드를 강제할 수 있습니다. 둘 다 사용하는 것도 가능합니다. 즉, 공개 플러그인 경계를 위한 프로토콜과 제공자 간의 공유 동작을 위한 내부 ABC입니다.저자는 더 가벼운 계약을 위해 프로토콜을 기본값으로 사용하고, 공유 구현이 필요하거나 추상 메서드의 런타임 강제가 필요할 때만 ABC로 전환할 것을 권장합니다. 플러그인 생태계의 경우, "상속으로 준수" (ABC)보다 "모양으로 준수" (프로토콜)가 종종 선호됩니다. 선택은 기본 요구 사항이 모양을 정의하는 것인지, 아니면 구체적인 동작을 공유하고 계층 구조를 강제하는 것인지에 따라 달라집니다.