デザインパターン一覧sellC,デザインパターンWikipediaベースに、自分の言葉で概要を整理しました。自分の投稿記事もここにまとめていきます。デザインパターン特にTECHSCOREさんの解説は利点がわかりやすい気がします。ライブラリ作成用なので、表の右2列に自作Cライブラリとその記事に関する情報も載せています。パターン名にwikiのリンクを張っています。これをベースに作ったライブラリパッケージの紹介がこちらになります。作成ライブラリ本体はこちらはとなります。利用者は抽象クラスCreaterのInterfaceを利用。Createrでは抽象クラス/インターフェイスProductを利用する。Productの実体生成はCreaterクラスの実装クラスに委ねる。Objectインスタンスの生成を1クラスのAPIにまとめ、さらにそのクラスも抽象化して実体を差し替えやすくする。MethodのFactoryも抽象化してしまおう!と考えると分かりやすい。元々は複雑なconstructをラップするためのもの。DirectorがBuilderインターフェイスのインスタンス&インターフェイスを包含。Director利用者はconstructを呼ぶだけでまとめてBuilder達の処理実行が行われる。クラスの状態を含めて一旦プロトタイプとして登録し、共有する。初期化に時間のかかる処理を実行した上で登録。みんなはそれを利用する形。いつクラスのインスタンスを取得しても、同じインスタンスが取得できるようにする。パターンに包含される。既存のインターフェイスを変更、利用した新規インターフェイスクラスを実現したい場合に利用。ベースのIFが無いとしょうがないので深堀はなし。利用されるAbstractionクラスに使うメソッドを全部用意せず、別インターフェイスクラスInplementorを用意。インターフェースに対して、ベースとなる実装クラスと、インターフェース実体を保持する装飾(Decorator)クラスを用意。(装飾クラスは各メソッド実行時に自処理⇒保持している実体の処理を実行)ベース/装飾クラスをコンストラクタで渡しつつ装飾クラスを生成していくことにより、インターフェースのメソッドを装飾し拡張していく。"同値"とみなしたインスタンスを同じインスタンスを利用して共有する。出力を変えないよう咬ませるラッパー。(主に同一IFで?)同一処理を行うオブジェクトをリスト化。Androidのボタンイベントみたいなイメージ。Colleague(Object達)の管理InterfaceであるMediatorを用意。使用者はMediatorを介してColleagueを利用。Colleagueとその使用者の結合度を下げる。ロールバック出来るようにする。同じメソッドの振る舞いを、状態ごとに変える。Cでもよくやるstate関数テーブルみたいなもの。戦略の与え方、使い方の問題。classで実装されているメソッド内で、抽象メソッドを実行。コアとなる共通処理は抽象メソッドに委ね、その実装により処理を変えられるようにする。実現するならライブラリ差し替え的な使い方の方がわかりやすそう。poolをまとめたかったので追加マルチスレッドのパターンについては、ほとんど「排他制御とは」を丁寧に説明すれば説明がつく気がするので、まとめて1つの記事で紹介します。排他系の処理に関してはpthreadのmutexやセマフォ、DBのトランザクション(私はsqliteくらいしかちゃんと把握していない)といったものに対する排他を思い浮かべていただけるといいかと思います。メソッドの呼び出し即実行ではなく、リクエストはメッセージキュー等に積みActorが処理を実施。前提条件が満たされていない場合は、(その時点での)処理の実行をあきらめる。2重起動防止や、起動シーケンスの際にレイヤーの違うアプリケーションの状態を気にせずinitializeを投げまくるようなケースが近い気がする。IMMEDIATE中の別のプロセス/スレッドからのBEGINへのエラー」といった、ロック中がチェックしてからロックをするようにした手法。エラーでなければロックするの説明からpthread_mutex_trylockが一番近いと思われる。別スレッドとの同期が必要な値取得の際に、いつになるかわからないけど結果が更新されてから取得するようにする。前提条件を満たすまで待つ機構。Futureと似た感じだけど、Futureは排他されたデータ取得し、使用者側はpthread_join/cond_signalやメッセージでトリガーをもらう。メソッドに対するスレッドセーフな仕組み。WebSocketのような通信を利用した同期方法。結果は後でいいからって考え。