C++ソフトウェア設計 読書会vol.33
https://scrapbox.io/files/677e58cd6851aa4933a854f0.jpeg
開催日時
2026年7月8日（水） 21:00～22:30
開催URL
参加人数
5人
ウォーミングアップ
7章
ガイドライン 28：物理的依存関係を排除するには Bridge パターン
問題点の例
見れてしまう
ソースコードはどうやっても見れてしまうのでは？
それこそバイナリ化でもしない限り
C#はデコンパイルさえできちゃう
Engineを仮想化しても何も解決していないような・・・？
公開できてしまうという文脈だった
std::unique_ptr<ElectricEngine> engine_;
pimplにunique_ptr使ってる
unique_ptrのテンプレート引数はincludeを使わず前方宣言だけのコードになっててよくない
仮想デストラクタが上手く動かない問題があったはず
解明 Bridge パターン
ElectricCarがElectricEngineを使いたい場合、キャストが必要になる
あんまりきれいじゃない
ElectricCarがCombustionEngineを保持できうる形なのがしっくりこない
ElectricCarのコンストラクタでしかEngineを指定できないつくりなのでそこで保証するつくりなんだろうけれど
ハイブリットエンジンになるとこの形が生きてくる？
ダイアモンド継承になる・・・
ここも例がよくない
Pimpl イディオム
PersonクラスだとそのImplメンバすべてにgetter,setterが必要になってImplの良さが出てこないかも
Implの中にmutexを入れてmoveさせる仕組みを見かけた
内部実装を使用者から隠せる
ヘッダ内のincludeなしstd::unique_ptrでもPerson.cpp内でPerson::~Person() = default;を記述すれば問題ないらしい
知らなかった
初見殺しコードではある
Bridge パターンと Strategy パターンの比較
次回ここから
お悩み雑談室
C#
C#だからってリークしないわけではない
メモリリークは回避できるかもしれないが、リソースはメモリ以外にもあってそれらがリークする
C#ってなんでUnityとかで採用されるのかいまいちよくわかっていない
UEのVerse
なんでこんな書式なの？
int x =ではなくx:int =で後置になるのなんで？
構文解析的に後置の方が有利なの？
最近の言語だと後置が多い
Rust
Go
用語集
ISP
インタフェース分離の原則
ISP は SRP の特殊なケースと捉える。
SRP
単一責任の原則
OCP
開放／閉鎖原則
LSP
サブタイプ(派生クラス)が満たすべきふるまい
リスコフの置換原則 (ガイドライン6)
サブタイプでは事前条件を強化してはならない
サブタイプは事後条件を弱めてはならない
サブタイプの関数の戻り型は共変（covariance）でなければならない
サブタイプの関数パラメータは反変（contravariance）でなければならない
スーパタイプの不変条件はサブタイプでも維持されなければならない
DIP
依存関係逆転の原則（ガイドライン9）
依存関係を管理するには、具象型や実装詳細ではなく抽象化に依存すべきである