著者は、2つの異なる画像生成バックエンドとやり取りするCLIツールのための共有コントラクトを設計していました。目標は、各バックエンドが独自のSDK呼び出しに変換する汎用的なsubmit(request)関数をCLIが使用できるようにすることでした。当初、著者は抽象メソッドの強制 due to their enforcement of abstract methods のために、抽象基底クラス（ABC）を共有インターフェースとして検討していました。しかし、ABCは継承を必要とし、これはサードパーティのプラグイン可能なバックエンドとの結合を生み出します。typing.Protocolは、構造的タイピングを使用するため、より適した選択肢として登場しました。クラスは、明示的な継承を必要とせずに、正しいシグネチャを持つ正しいメソッドを持つことでProtocolを満たします。このアプローチは、外部実装者をコアパッケージから分離し、プロバイダーが独立して進化できるようにします。Protocolは、プロバイダーが厳格な階層の一部ではなく値として渡される、コンポジションベースの設計を促進します。Protocolはプラグイン境界を記述するのに理想的ですが、プロバイダーが具体的な動作や実装ロジックを共有する必要がある場合は、ABCの方が適しています。ABCは共有メソッドを定義し、具体的なサブクラスが実装しなければならない抽象メソッドを強制することができます。両方を使用することも可能です。公開プラグイン境界のためのProtocolと、プロバイダー間の共有動作のための内部ABCです。著者は、より軽量なコントラクトのためにProtocolをデフォルトで使用し、共有実装が必要な場合や、抽象メソッドの実行時強制が望ましい場合にのみABCに切り替えることを推奨しています。プラグインエコシステムの場合、「形状による適合」（Protocol）は、「継承による適合」（ABC）よりもしばしば好まれます。選択は、主なニーズが形状を定義することであるか、具体的な動作を共有し階層を強制することであるかによって異なります。