オブジェクト指向設計原則
オブジェクト指向設計原則 (オブジェクト指向設計原則)
LSP: リスコフ置換原理
リスコフ置換原理
-
サブクラスは、親クラスにない制約を追加することはできません。
-
サブクラス オブジェクトはスーパークラス オブジェクトを置き換えることができる必要があります
-
例: square クラスには長さと幅に制限があるため、square クラスを使用して Rectangle クラスを継承することはできません。
OCP: オープンクローズ原則
開閉原理
オープンクローズ原則では、ソフトウェア エンティティは拡張に対してはオープンであり、変更に対してはクローズされるべきである、つまり、既存のソース コードを変更せずにその動作を変更できるということです。
オープン・クローズド原則を実現するための 2 つの戦略
戦略 1: バートランド マイヤーの戦略 (古い方法)
インターフェイスではなく実装 (コード) を再利用します。
クラスは、コード エラーを修正する目的でのみ変更する必要があります。機能を追加または変更するには、別のクラスを作成する必要があります。
- 新しいクラスは、継承を通じて元のクラスのコードを再利用します。
- サブクラスはスーパークラスとは異なるインターフェイスを持つ場合があります
戦略 2: 1990 年代の新しい考え方
実装 (コード) ではなく、抽象インターフェイスを再利用する
インターフェイスは変更されず、システム機能は新しいサブクラスを追加することによって拡張されます。
-
実装コードが変更される可能性がある場合は、抽象インターフェイスを使用します。
-
複数の実装を作成し、多態的に相互に置き換えることができます。
SRP: 単一責任原則
単一責任の原則
クラスに関する限り、その変更の理由は 1 つだけ、つまり責任は 1 つだけである必要があります。
-
SRP は凝集性 (Cohesion) を具体化します。 Cohesion: モジュールの構成要素間の機能的な相関関係
-
クラスが複数の責任を負う場合、その変更には複数の理由が考えられます (1 つの責任のみを実行できるクラス、複数の責任を実行できるクラスに相当し、異なる責任間に干渉が発生する可能性があります)。
ISP: インターフェース分離原則
インターフェース分離の原則
クライアント クラスは、必要のないメソッドに強制的に依存すべきではありません。
実際のアプリケーションでは、特定のクラスの一部のメソッドのみを考慮すると、他のメソッドがインターフェイス汚染を引き起こすことになります。
-
インターフェイス分離原則の重要性: ISP 原則によれば、大きなインターフェイスはより小さく、より具体的なインターフェイスに分割されるため、クライアント クラスは関心のあるメソッドのみを知る必要があります。
-
ISP 原則の目的は、システムの結合を少なくして、より簡単にリファクタリング、変更、展開できるようにすることです。
-
実装方法：大きなクラスを独立した意味を持つ小さなクラスに分割する
DIP: 依存性逆転の原則
依存関係逆転の原則
高レベルのモジュールは低レベルのモジュールに依存せず、両方とも抽象化に依存します
制御の反転 (IoC、制御の反転)、依存関係の注入とも呼ばれます。
- 実装ではなくインターフェイスに対するプログラム
- 依存関係逆転原則の違反:
- 依存関係逆転の原則を適用します。
ヒューリスティック原理
「抽象化に依存する」 - プログラム内のすべての依存関係は抽象クラスまたはインターフェイスで終了する必要があります。
ヒューリスティック原則:
- 変数には具体的なクラスへのポインタまたは参照を含めてはいけません
- クラスは具象クラスから派生してはなりません (抽象クラスは継承でき、インターフェイス クラスは実装されます)。
- どのメソッドも、その基本クラスですでに実装されているメソッドをオーバーライドしてはなりません
構造化設計とオブジェクト指向設計の違い
構造化されたデザイン
上位層が下位層を呼び出し、上位層が下位層に依存するため、下位層が大幅に変更されると、それに合わせて上位層も変更されるため、モジュールの再利用性が低下し、開発コストが大幅に増加します。
オブジェクト指向設計
依存性の逆転: 一般に、抽象化が変更される確率は非常に小さいため、クライアント クラスは抽象化に依存し、実装の詳細も抽象化に依存します。
実装の詳細が常に変化しても、抽象化が同じであれば、クライアント プログラムを変更する必要はありません。これにより、クライアント プログラムと実装の詳細の間の結合が大幅に軽減されます。