第06回: Observerパターン — 「通知する側」と「受け取る側」を切り離す
注文完了後にメールを送る。さらにSlackに通知する。さらに在庫を更新する。さらに分析ログを記録する——。
Category
注文完了後にメールを送る。さらにSlackに通知する。さらに在庫を更新する。さらに分析ログを記録する——。
ソートアルゴリズムを切り替えたい、送信方法を切り替えたい、価格計算ルールを切り替えたい——。こうした「処理を差し替えたい」要求は実務で頻繁に起きます。
クラス内部で new DBConnection() を書いたとき、そのクラスは特定のDB実装と密結合します。テストのたびに本物のDBが必要になり、実行が遅く、不安定になります。
修正のたびに既存テストが壊れ、バグが混入するリスクが高まります。 SOLID原則は理論として読むだけでは意味がありません。実際のクラス設計で適用して初めて力を発揮します。
「このコード、手を入れるたびに予期しない場所が壊れる」——チームで共有した経験ではないでしょうか。 原因のほとんどは、クラスが複数の責務を抱え込んでいるか、依存関係が複雑に絡み合っていることにあります。