デザインパターンは、コードが1つまたは複数の設計原則に対応するように設計されているため、オブジェクト指向の設計原則は設計パターンの基本的な考え方と言えます。
デザインパターンの7つのデザイン原則の核となるアイデア:
- 単一責任の原則: 単一責任の原則
- オープン クローズド プリンシプル: オープン クローズド クローズド プリンシプル
- Liskov Substitution Principle: リスコフ置換原理
- Law of Demeter: Law of Demeter (最小知識の原則)
- インターフェイス分離の原則: インターフェイス分離の原則
- 依存関係逆転の原則: 依存関係逆転の原則
- 複合再利用の原則: 合成再利用の原則
また、SOLID を使用して設計原則、イニシャルの組み合わせを表す人もいます。複合再利用の最後の原則は、十分に古典的ではなく、違反するのは容易ではないと考えられています。
単一責任の原則
クラス (モジュールと同じくらい大きいか、関数と同じくらい小さい) は 1 つのことだけを行い、オブジェクトの粒度はそれ自体で定義する必要があります。
外部の理由によりメソッドを書き直す必要がある場合、このメソッドには 2 つの原則があると考えることができます。
メソッドがあまりにも多くの責任を負っている場合、要件の変更に応じてメソッドを書き直す必要が生じる可能性が高くなります。
2 つの責任が結合されている場合、1 つの責任の変更が他の責任の実装に影響を与え、予期せぬ損害を引き起こす可能性があり、この結合により結束が低く脆弱な設計になります。
単一の責任は、高い結束と低い結合を完全に体現し、コードの再利用性、可読性、保守性を向上させます。.
実際の開発プロセスにおいても、過度な設計は避けるべきであり、最初は比較的粗いモジュールを作成し、モジュールが大きくなると分割し、いわゆる継続的なリファクタリングを行うことができます。
単一かどうか判断できない場合は、コード量、依存関係量、private メソッド数から計測します。
webpack のローダーと同じように、style-loader と css-loader を 1 つに統合することができますが、いいえ、両方を自分でインストールする必要があります。これは、組み合わせて使用することも、個別に使用することもでき、単一責任の原則に準拠しています。
オープン クローズ クローズの原則
ソフトウェア エンティティ (クラス、モジュール、関数) などは拡張可能であるべきですが、変更可能ではありません。つまり、拡張用に開いていますが、変更用に閉じています。
拡張に対してオープンであるということは、新しい要件や変更がある場合に、既存のコードを拡張して新しい状況に適応できることを意味します。
変更に対して閉じているということは、クラスが設計されると、クラスを変更することなく、その作業を独立して完了することができることを意味します。
ほとんどの設計パターンは、コード品質の重要な指標であるコードのスケーラビリティを解決するように設計されています。
また、修正をクローズするということは、コードがずっと積み上げられていることを意味するのではなく、可変部分と不変部分をできるだけ見つけ出し、コードをまったく変更しないのではなく、変更を少なくすることにも注意する必要があります。 .
開発においてオープンとクローズの原則を適用するために最も重要なことは、ビジネスまたは機能を明確に理解し、将来追加される可能性のある機能またはそれらの使用方法を知ることです。
リスコフ置換原理
基本/親クラスが表示される場所には、必ずサブクラスが表示されます。また、元のプログラムの論理的な動作が変更されず、正確性が損なわれないことを確認してください。Liskov 置換原理は、「open-closed」原理を補足するものです。
サブクラスは親クラスを置き換えることができますが、親クラスの変更はすべてのサブクラスに影響します。
サブクラスが親クラスのロジックを書き換える場合、最終的な実装は親クラスに違反することはできません。違反しないと、Liskov 置換原則に違反します。
デメテルの法則 (最小知識の原則)
ソフトウェア エンティティは、他のエンティティとのやり取りをできるだけ少なくする必要があります。各ソフトウェア ユニットは、他のユニットに関する最小限の知識しか持たず、そのユニットに密接に関連するソフトウェア ユニットに限定されます。
ディミットの法則の本来の意図は、クラス間の結合を減らすことです。各クラスは他のクラスへの依存を最小限に抑えるため、システムの機能モジュールを独立させることが容易であり、それらの間に依存関係がまったく (またはほとんど) ありません。
インターフェース分離の原則
クライアントは、必要のないインターフェースに依存すべきではありません。単一の汎用インターフェースを使用するよりも、複数の専用インターフェースを使用する方が適切です。クラスの別のクラスへの依存は、最小のインターフェイスに基づく必要があります。
インターフェースは、必ずしも API インターフェース、つまり要求インターフェースとして完全に理解されているわけではありませんが、関数またはクラスの呼び出しとして理解することもできます。
インターフェース分離の原則は、単一責任の原則に似ています. インターフェースを可能な限り単純にし、インターフェースをより細かい部分に分割することです. 単一責任の原則は、モジュール、クラス、およびインターフェースの設計を目的としています. . インターフェイス分離の原則は、インターフェイスの設計により重点を置いています。
依存性逆転の原則
プログラムは、具体的な実装ではなく、抽象的なインターフェイスに依存する必要があります。簡単に言えば、実装ではなく抽象化をプログラムする必要があるため、クライアントと実装モジュール間の結合が減少します。
プロセス指向開発では、上層が下層を呼び出し、上層が下層に依存するため、下層が大きく変化すると上層もそれに合わせて変化するため、モジュールの再利用性が低下し、コストが大幅に増加します。開発の。
オブジェクト指向開発はこの問題をうまく解決します. 一般に抽象化の可能性は非常に小さいため, ユーザープログラムは抽象化に依存し, 実装の詳細も抽象化に依存します. 実装の詳細が常に変化していても、抽象化が同じである限り、クライアント プログラムを変更する必要はありません。これにより、クライアント プログラムと実装の詳細の間の結合が大幅に減少します。
理解するのは少し抽象的ですが、私が JavaScript で理解しているのは、コールバックとパラメーターの受け渡しによって依存関係を切り離す高階関数です。typescript の出現は、JavaScript における依存関係逆転の原則のより良い実装ですか?
合成再利用の原則
再利用の目的を達成するために、継承の代わりにオブジェクト構成を使用するようにしてください。JavaScript では、合成再利用の原則をより推奨する必要があります。例えば、関数 A は関数 B のいくつかの関数を使用しており、それらは継承され、渡されたパラメーターと使用する変数を使用します. 複合再利用の原則が使用されている場合、パラメーターまたは変数を渡して関数 B の関数を呼び出すことです.継承され、関数 A と関数 B が結合されます。
いくつかの設計原則を理解した上で、過度の設計に十分注意し、設計原則のために実際の意味を超えて設計しないようにする必要があります。たとえば、オープンとクローズの原則では、将来必ずしも必要とされない機能や、長期間必要となる機能について、非常に複雑な設計を行うべきではありません。自分だけが理解できる機能を設計しないでください。
設計原則には主観的な判断と理解が含まれることがあり、ほとんどの場合、非常に多くの原則に準拠することは困難です。また、ある原則に準拠していても別の原則に違反している場合もあります。少し理解できたような気がしますが、実際の適用は別の問題であり、いくつかの原則は非常に抽象的で、フロントエンド開発にはあまり適していません。また、いくつかの原則についてはまだ良い概念がありません。
個人的なメモをコーディングするサブスクリプション番号に注意を払うことを歓迎します