"container_of"パターンの実名

Question

など。 Linuxドライバの開発では、container_ofマクロを見つけることができます。本質的には、->とは逆の演算子であり、メンバーへのポインタがあれば、それを含む構造体へのポインタを生成します。

Greg Kroahのブログ以外にも、私はこのパターンをPintosのlistとhash実装で見つけました。

Answer 1

このパターンの実際の名前は「container_of（）」です。このC-ismをJavaまたはC++のデザインパターン分類に適合させる試みは無駄です。重要な点は、責任を連鎖させることではなく、何かを指定または委任することではありません。これらの点で考える必要がある場合、それは「乱雑な一般化された継承」です。これらの点で考える必要がなければ、それほど面倒ではありません。

Answer 2

私はそれが非常に特徴的ではないと思います。Chain Of Responsibility。親コンテナ構造体にポインタを戻す必要がある唯一の理由は、含まれている要素の範囲内に親コンテナ機能を配置することです。したがって、はとなります。これは、正しい「レベル」で処理されるまで、「チェーン」をトリックルするリクエストを許可するために必要な実装の詳細です。

コンテナ/含まれている関係では、「正しい」レベルは1つ上のレベルに過ぎず、理想的な例として、トリクルアップでは十分なレベル（1つのレベルしかないため）がありません。パターン。それでも、Chain of Responsibilityの背後にある一般的な考え方はまだ成立しています。それを扱うことができないチェイン内のポイントでリクエストが行われ、変更の別のポイントで処理されます。

小さな非ジェネリックコンテナ/含まれた関係では、この2つのリンクチェーンのカップリングは非常にきつくなります。例えば、あなたの例では汎用的な「コマンド」処理フレームワークがない（コマンド言語セットが小さいため）、そのようなフレームワークは一般的に（型安全性のために）コマンド/メッセージオブジェクトを必要とする。これは、要素がリストから削除したい要素レベルで直接通知するようにするためのオーバーヘッドです。

はい、there is a C2 pattern's page for it ...私の推論に同意する場合。