#input - [[🗃️SOLID原則]]は、[[🗃️オブジェクト指向]]の開発だけでなく、[[🗃️ソフトウェア]]一般に応用できる。 ## 5-2 [[🗃️単一責任原則(SRP)]] - 単一責任だと、モジュールの交換が容易になる。 - 例: ニュース記事管理システム - 購読と入稿は、別々に分かれていて欲しい - データベースドライバはどうか？ - reactとwriteで分けてしまうと、チグハグになってしまう - 一緒にするとしたら、どのような概念として単一責務があると言えば良いのか？ - 「バージョンを明確に区別できる」方が優先と考えても良い - [[🗃️全再利用の原則(CRP)]]と[[🗃️閉鎖性共通の原則(CCP)]]の考え方と同じように、一度に再利用されるものは分散することなく一つのパッケージにまとまっているのが適切。 ## 5-3 [[🗃️開放閉鎖原則(OCP)]] - [[🗃️安定度・抽象度等価の原則(SAP)]]の発想が役にたつ。 - FizzBuzzのケースが載っていた。 ## 5-4 [[🗃️リスコフの置換原則(LSP)]] - [[🗃️リスコフの置換原則(LSP)]]は、正しい[[🗃️継承]]とは何かを述べた原則。 - 派生クラスは常に同じ使い方を保証しないといけない。 ## 5-5 [[🗃️インターフェース分離の原則(ISP)]] - メリット - 無関係なメソッドが見えなくなり、使い方が簡単になる - 呼び出されるメソッドを限定できて、問題分析しやすくなる - 別のクラスで代替しやすくなる。 - [[🗃️Interface(抽象型)]]は、「使用者が認識する部分概念」 - 補足、外部の[[🗃️クラス]]と接続するのが良い。 ## 5-6 [[🗃️依存性逆転の原則(DIP)]] - 象徴的な原則。 - [[🗃️構造化プログラミング]]は、アプリケーション全体を部分的な小さな機能部品に分けて、その小さな機能部品をさらに小さな詳細機能に分けて作る方針。 - ただこれは、上位構造の正しさが、下位の実体の動作に依存してしまう問題がある。 - 抽象の実装を生かせば、依存の向きは、必ずしも制御の向きと同じではなくてよくなる。 - → 安定した方に依存を向けることができる。