Автор разрабатывал общий контракт для CLI-инструмента, взаимодействующего с двумя различными бэкендами для генерации изображений. Цель состояла в том, чтобы позволить CLI использовать универсальную функцию submit(request), при этом каждый бэкенд преобразовывал бы ее в вызовы своего собственного SDK. Изначально автор рассматривал использование абстрактных базовых классов (ABC) в качестве общего интерфейса из-за их принудительного применения абстрактных методов. Однако ABC требуют наследования, что создает зависимость для сторонних подключаемых бэкендов.typing.Protocol оказался более подходящим решением, поскольку он использует структурную типизацию. Класс удовлетворяет протоколу, имея правильные методы с нужными сигнатурами, без необходимости явного наследования. Такой подход отделяет внешних реализаторов от основного пакета, позволяя поставщикам развиваться независимо. Протоколы способствуют дизайну, основанному на композиции, где поставщик передается как значение, а не является частью строгой иерархии.Хотя протоколы идеально подходят для описания границ плагинов, ABC более уместны, когда поставщики должны совместно использовать конкретное поведение или логику реализации. ABC может определять общие методы и принудительно применять абстрактные методы, которые должны реализовать конкретные подклассы. Также возможно использовать оба подхода: протокол для внешней границы плагина и внутренний ABC для общего поведения среди поставщиков.Автор рекомендует по умолчанию использовать Protocol из-за его более легкого контракта, переходя к ABC только тогда, когда требуется общая реализация или когда необходимо принудительное применение абстрактных методов во время выполнения. Для экосистем плагинов "соответствие по форме" (Protocol) часто предпочтительнее, чем "соответствие по наследованию" (ABC). Выбор зависит от того, является ли основной потребностью определение формы или совместное использование конкретного поведения и принудительное применение иерархии.