C++ソフトウェア設計 読書会vol.17
https://scrapbox.io/files/677e58cd6851aa4933a854f0.jpeg
開催日時
2025年9月17日（水） 21:00～22:30
開催URL
参加人数
6人
ウォーミングアップ
次回のcpp breaktime
12/19開催予定！
用語集
ISP
インタフェース分離の原則
ISP は SRP の特殊なケースと捉える。
SRP
単一責任の原則
OCP
開放／閉鎖原則
LSP
サブタイプ(派生クラス)が満たすべきふるまい
リスコフの置換原則 (ガイドライン6)
サブタイプでは事前条件を強化してはならない
サブタイプは事後条件を弱めてはならない
サブタイプの関数の戻り型は共変（covariance）でなければならない
サブタイプの関数パラメータは反変（contravariance）でなければならない
スーパタイプの不変条件はサブタイプでも維持されなければならない
DIP
依存関係逆転の原則（ガイドライン9）
依存関係を管理するには、具象型や実装詳細ではなく抽象化に依存すべきである
ガイドライン14：デザインパターン名を用い目的を伝える
この名前そこまでぴんと来ない
UnaryCommand
ユーナリィコマンド
意味のある名前にすることには同意
なんちゃらBuilderがビルダーパターンに則していないクラスがある・・・
UEは適切にデザインパターン名を使っている
天下のEpic様なので
std::variantに対してVisitorを使う形
実際こういう形使います？
あんまり使わない
型が欲しいことが結構ある
こういうパターンを採用すると関連する部分も統一する必要が出てくる
エンジンの中とかだと一貫性も必要
実際に使った
基底クラスがしっかりしてなくても呼び出せる
自由度はある
けれどそれはメリットなのか・・・？
とりあえず初期化を呼び出せるのが助かった
4章 Visitor パターン
ガイドライン15：型または処理の追加に備え設計する
手続き型プログラミングの解
draw()がグローバルに存在するんだ
それにSquareとかを引数にとるんだ
テストとかどうするんだろう？
新人や学生が書きそうなコード
Shapeでまとめてvectorで持たず、CircleとSquareを別々のvectorにしたい
基底クラスがあるなら仮想関数を使いなよ・・・
どうすれば保証できるでしょうか？
grep
全文検索
今ならAIに聞くとか
switchケース追加漏れでQAさんから怒られた
あるある
一概に型が悪いのではない
型を使ってももう少し設計がよければ回避できる
今の例は最悪な書き方をあえてしている
それを悪夢というのは・・・
オブジェクト指向の解
次回ここから
お悩み雑談室
次回のcpp breaktime
ryutorionさん発表OK!
何が聞きたい？
何かしらのエンジン拡張の話が聞きたい
調べたものが無駄になることが怖い
例
GPGPUの記述言語
CUDA以外
マイクロソフトの消えていった各種技術
自分の時間を無駄にしたくない
無駄になって段々勘が身についてくる
これダメだな、みたいな勘
sycl