ソフトウェア設計またはパターンの「ティアオフ」とは何ですか？
ティアオフとは何ですか？ Flutterのドキュメント を読んで、
PluginUtilities.getCallbackFromHandleに提供して、元のコールバックのtear-offを取得できるCallbackHandleを返します。
用語をググるだけで、私が理解しているが関係のない「切り取りメニュー」が生成されるようです。
「ティアオフ」パターンとは何ですか？
「ティアオフ」の考え方は、いくつかのオブジェクトによって提供される機能があるということですが、-実際に機能を提供するものは、あなたが話しているサービスプロバイダーとのアイデンティティを持っていません。 to。
1990年代に心を向け、COMプログラマーだと想像してみてください。 COMは、Cのようにオブジェクトを直接サポートする必要のない言語からオブジェクト指向プログラミングを行うためのバイナリ標準です。COMプログラミングの基本的な方法はIUnknown::QueryInterfaceは、インターフェイスを一意に識別する番号を取り、失敗するか、そのインターフェイスを実装するオブジェクトへのポインタを提供することによって成功します。すべてのCOMインターフェイスはIUnknownを継承するため、すべてのCOMオブジェクトはQueryInterfaceをすべてのインターフェイスに実装します。
COMサーバーを実装しているとしましょう-覚えておいてくださいサーバーはサービスを提供するオブジェクトです;サーバーをマシンとは考えないでください-C++クラスと見なして、IFooとIBarを実装することを望んでいます。どちらももちろんIUnknownから派生しています。通常、これを行うには、IFooとIBarの抽象クラスを作成し、それぞれにグローバルに一意の番号を割り当てて、C++クラスにQueryInterfaceを実装して、適切な抽象クラスへのthisポインターをcasts返し、キャストポインタ。 複数のインターフェースを実装する標準的な方法は、抽象基本クラスの多重継承です（実際にはlogicallyは参照IDを保持していますが、実際にはポインタは等しくないことが許可されていますそして、通常です。）
しかし、QueryInterfaceの必須は、成功すると、正しいvtableを持つオブジェクトへの有効なポインタを返すということだけです。 要件はありません。QueryInterfaceは、多重継承されたインターフェースへのキャストを介して実装されます。 QueryInterfaceがIFooに対してQIを行ったときに別のオブジェクト全体を返し、IBarに対してQIを行ったときに別のオブジェクト全体を返すことで契約を実装することは完全に合法です。 （次に、IFooのIBarオブジェクトをQIしたときに何が起こるかについていくつかの複雑な問題がありますが、おそらくそれらの処理方法を確認できます。）
「引き離しインターフェース」と呼ばれるこの実装の選択を好むパフォーマンスとプログラムアーキテクチャの理由があります。重要なのはサービスを要求されると、オブジェクトはサービス自体を実装するのではなく、そのサービスを実装する別のオブジェクトを返却することです。
「設計パターン」の観点から、「引き裂き」パターンは、「責任の連鎖」などのこの問題のより複雑なソリューションへの最初のステップであると思います。 「責任の連鎖」では、サービスにオブジェクトを要求すると、オブジェクトがサービスを提供するか、「必要なサービスを提供できませんが、他の誰かが知っている可能性があります...」と表示され、要求が転送されます。プロバイダーのチェーン。 （COMでは、「責任の連鎖」はIServiceProvider :: QueryServiceによって表されます。）
Dartは「ティアオフ」を使用して同様のことを意味しているようですが、インターフェイス全体ではなく、単一の関数の場合のみです。つまり、「ティアオフ」は、元のオブジェクトからdistinctであるオブジェクトですが、-そのオブジェクトによって提供されるサービスを表す、つまり、メソッドを呼び出す機能です。これはC＃ではdelegateと考えます。