C++ソフトウェア設計 読書会vol.28
https://scrapbox.io/files/677e58cd6851aa4933a854f0.jpeg
開催日時
2026年4月8日（水） 21:00～22:30
開催URL
参加人数
6人
ウォーミングアップ
ガイドライン 24：インタフェースを統一するには Adapter パターン
Adapter パターンの短所を分析
カモと七面鳥の例がまったくピンとこない・・・
鳴き声の種類がわからない・・・
一緒に扱うときにアダプタを作らずBirdクラスを作るべきだったのでは
アヒルの一団に七面鳥を加えて合唱させるコード
これはアヒルの一団に七面鳥を加えたプランナーが悪い・・・
プログラマはアダプタを作るのでもBird基底クラスを作るのでもなくプランナーの意見を却下すべきだった
これやろうと思えば蜜柑に叫ばせたり飛ばせたりするアダプタが作れるよね
昨今のAIがこんな風に書きそう
ガイドライン 25：通知を抽象化するには Observer パターン
メッセンジャアプリの例もわかりにくい・・・
この人にとってはわかりやすいのかな
登録しておいて変化があったら通知がくる
解明 Observer パターン
MVCアーキテクチャ
マイクロソフト的にはMFC
モデルが変更されると影響するViewに通知が行く
↑の方が本の例よりもわかりやすい
Observer パターンの古典的実装
次回ここから
お悩み雑談室
会社で輪読会の話が出てる
Googleのソフトウェアエンジニアリング
コードのクオリティを上げよう、が目的
難しい目的
それぞれ並列でやった方が効率的？
わからないところをSlackで
読んで内容を理解しよう、を目的にしてもいいのでは
用語集
ISP
インタフェース分離の原則
ISP は SRP の特殊なケースと捉える。
SRP
単一責任の原則
OCP
開放／閉鎖原則
LSP
サブタイプ(派生クラス)が満たすべきふるまい
リスコフの置換原則 (ガイドライン6)
サブタイプでは事前条件を強化してはならない
サブタイプは事後条件を弱めてはならない
サブタイプの関数の戻り型は共変（covariance）でなければならない
サブタイプの関数パラメータは反変（contravariance）でなければならない
スーパタイプの不変条件はサブタイプでも維持されなければならない
DIP
依存関係逆転の原則（ガイドライン9）
依存関係を管理するには、具象型や実装詳細ではなく抽象化に依存すべきである