この記事について
- Clean Architecture 達人に学ぶソフトウェアの構造と設計を読んだ際の覚え書きです
覚え書き
アーキテクチャの観点からリスコフの置換原則（LSP）を理解するにはこの原則に違反した時にシステムのアーキテクチャに何が起こるのかを考えてみるのが一番だ。
RESTfulサービスのインターフェイスが置換可能になっていないせいで、アーキテクトは複雑な仕組みを追加することになってしまった。
- 違反の例としてRESTful APIのパラメータ名がユーザーごとに違った場合を例に挙げている
- １つのRESTful APIを１つのサービスで実装しているため、ユーザーごとのパラメータ取得処理を作るとアーキテクトが複雑になってしまう
- １つのRESTful APIに応答するサービスをユーザーごとに作成すればアーキテクトが複雑にならない
- この例ではパラメータ名の切り替えなのでRESTful APIに応答するサービスを作成するのと、データベースにURIをキーにする設定を登録するのでは差異がないように感じる
- サービスを分けることによってユーザーごとの差分には対応しやすくなる
- SRP：単一責任の原則に関連して一つのユーザーに対応するためシンプルになる（複雑なアーキテクトにならない）
今ではインターフェイスと実装に関するソフトウェア設計の原則になっている。
対象となるインターフェイスにはさまざまな形式がある。Java風のインターフェイスは、それを実装したクラスをいくつも作れる。Rubyであれば、同じメソッドシグネチャを共有するクラスをいくつも作れる。ウェブであれば、同じRESTインターフェイスに応答するサービスをいくつも作れる。
- リスコフの置換原則はクラスとインターフェイスに限った話ではなく、言語、アプリケーションの種類に関係なくユーザーとの接点で発生するもの
- ウェブの話は意識できていなかったので普段から気付けるようにしたい
まとめ
- ユーザー（人、サービス、クラス）に対するインターフェイスではIFで分岐せず、置換可能にすることで複雑なアーキテクト（実装）にならないようにしたい
