単一責任の原則

1つのクラス・モジュールが1つのアクターに対して責務を負うべきであるという原則
ソフトウェアシステムに手を加えるのは、ユーザーやステークホルダーを満足させるためであり、ユーザーやステークホルダーこそが、単一責任の原則が指す「変更する理由」である。

アクターの異なるコードは分割すべき

いなか

オープン・クローズドの原則

ソフトウェアの構成要素は拡張に対していは開いていて、修正に対しては閉じていなければならない

変更が発生した場合に、既存のコードには修正を加えずに、新しくコードを追加するだけで対応できるような設計にすること

いなか

リスコフの置換原則

SがTの派生型であれば、プログラム内でT型のオブジェクトが使われている箇所は全てS型のオブジェクトで置換可能

サブタイプ

型Tに対して is-a 関係である型SはTのサブタイプであると言える。反対にTはSのスーパータイプとなる。

※「タイプ」は実装の概念を含まない。あくまでインターフェースの型のみ

is-a 関係

「B is a A」BはAの一種であるということ。
継承を使用することで、スーパークラスの持っているプロパティやメソッドを全て引き継いだサブクラスが成立できる。

事前条件と事後条件のルール

事前条件（呼び出し側が守らなければいけない条件）はスーパータイプと同一か、それよりも弱めることができる。反対に条件を強めることはできない。
事後条件（呼ばれる側が守らなければいけない条件）はスーパータイプと同一か、それよりも強めることができる。反対に条件を弱めることはできない。

いなか

インターフェース分離の原則

インターフェースの継承先で使わないメソッドがないようにインターフェースを分離する

必要となる最小限の機能ごとにインターフェースを分ける
必要なインターフェースのみを全て継承する

いなか

 依存性逆転の原則プログラムの重要な部分が、データベースやWebフレームワークなどを用いる部分に依存しないよう設計すべき

依存する側（importやuseする側）がモジュールを直接呼び出すのではなく、抽象クラスやインターフェースを使い「抽象」に依存しようというもの

 DI（依存性の注入）コードの柔軟性と再利用性を高めるための設計パターン。通常、あるクラスが別のクラスに依存している場合、その依存関係はコード内で直接作成されるが、DIを使用すると、これらの依存関係を外部から注入することができる。

依存性を「オブジェクト」と読み替えると理解しやすい

 なぜDIが重要なのか従来のプログラミングでは、クラス内で直接依存しているオブジェクトを生成していたが、以下の問題が生じる。
テストの困難さ
依存オブジェクトが固定されているため、テスト時に別のオブジェクトを利用するのが難しい

コードの再利用性の低下
依存オブジェクトが変わるとクラス自体も変更する必要がある

密結合
1つの部品の変更が他の部品に波及しやすい


 DIのメリットテストの容易さ
テストにモックオブジェクトやスタブを簡単に注入できる

疎結合
オブジェクトの依存関係を外部から注入することで、クラスは具体的な依存関係の詳細を知らずに済む

再利用性と保守性の向上
疎結合により、クラスやコンポーネントが再利用しやすくなる
一部のコンポーネントを修正しても、その変更がシステムの他の部分に影響を与えにくくなる

可読性向上と管理のしやすさ
拡張性の向上
新しい機能やコンポーネントを追加する際に、既存のコードを大幅に変更する必要がなくなる

設計原則との相性
「依存性逆転の原則（Dependency Inversion Principle）」に直接関連しており、より健全な設計を促進する

いなか

 例外処理想定内のエラーが起きた時に、その内容に応じて実行される処理のこと。

もしプログラムに適切な例外処理が実装されていない場合、プログラム実行中にエラーが発生すると意図しない構造のデータが保存されたり、異常終了してしまう事態を招く。

また、その時に発生したエラーを調査するのに時間がかかってしまう。

 業務エラー指定フォーマットの違い（メールアドレスなど）
一意チェック（ユーザーの重複）
必須項目の存在

など、主にユーザーの誤入力・誤操作が原因
ユーザーに誤入力・誤操作を取り消してもらい、正常な入力・正常な操作を行なってもらうことが対処方法となる。

何が誤入力・誤操作だったのかをユーザーに指摘する。具体的なメッセージを画面を用いて表示させることが適切。

 システムエラーサーバーが停止している
データベースに接続できない
プログラムのバグ

など、主にユーザー側で対処することができないエラー
システム開発者がプログラムを修正することが対処方法となる。

バグが原因のエラーが発生した後にプログラムを実行してしまうと、以降のプログラムの実行結果が正しいことが保証できないため、安全に終了してもらう必要がある。

素早く対応するためにも、ログにエラー内容を出してエラー監視を行う。