一般的な設計原則を例とともに詳細に説明

デザイン原則は、デザインパターンが構築される基礎を形成します。実証済みの設計原則に従うことで、コードはより柔軟になり、変更に対する耐性が高まり、保守しやすくなります。

共通の設計原則

• シンプルさの原則 (KISS)
  KISS 原則の目標は、コードをシンプルに保ちながらもシンプルになりすぎず、不必要な複雑さの導入を避けることです。

• 同じことを繰り返さないでください (DRY)
  BRY 原則ですが、その目的は、共通する部分を取り出して別の場所に配置することで、システムの一部の重複を避けることです。もちろん、避けられているのはコードだけではなく、ビジネス ロジックも避けられています。

• 尋ねるな、教えてください
  この原則は、オブジェクトの状態について質問してからオブジェクトに実行してもらいたいアクションを決定するのではなく、オブジェクトに実行してもらいたいアクションを伝えるべきであると述べています。これは、責任を一致させ、クラス間の密接な結合を回避するのに役立ちます。

• それは必要ありません (YAGNI)
  この原則は、必要と思われる他の機能を追加しようとせず、アプリケーションに必要な機能のみを含めることを指します。

• 懸念の分離 (SoC)
  SoC は、ソフトウェアを個別の関数に分解するプロセスであり、それぞれの関数には、他のクラスで使用できる固有の動作とデータがカプセル化されます。通常、懸念はクラスの機能または動作を表します。プログラムを独立した責任に分割すると、コードの再利用、保守性、テスト容易性が大幅に向上します。

S.O.L.I.D の設計原則

• 単一責任原則 (SRP)
  SRP は懸念事項の分離原則と高度に一致しています。各オブジェクトには責任の焦点が 1 つだけある必要があります。つまり、クラス変更の理由は 1 つだけです。

• オープンクローズ原則 (OCP)
  この原則では、クラスが拡張に対してオープンであり、変更に対してクローズである必要があるため、クラスの内部動作を変更せずにクラスに新しい機能を追加できる必要があります。また、クラスが破棄されて不要なエラーやバグが発生することを避けます。

• リスコフ置換原理 (LSP)
  親クラスは、動作を変更せずにサブクラスで置き換え可能である必要があります。変更原則は OCP 原則と一致しており、継承されたクラスが親クラスの動作に影響を与えないようになっています。

• インターフェイス分離原則 (ISP)
  ISP 原則は、責任に応じてインターフェイス メソッドをいくつかのグループに分割し、これらのグループに異なるインターフェイスを割り当てることに重点を置いています。クライアントが巨大で未使用のインターフェイスを実装しないようにします。

• 依存性反転原則 (DIP)
  DIP 原則の目的は、作成したクラスを特定の実装から分離し、これらのクラスが抽象化またはインターフェイスに依存するようにすることです。これはインターフェイス指向のプログラミングを促進し、コードが特定の実装に密接に結合されないようにし、それによって邪悪なシステムの柔軟性を高めます。

• 依存性注入 (DI) と制御反転 (SoC) の原則
  DI、SoC、DIP は密接に関連しています。 DI は、コンストラクター、メソッド、またはプロパティを通じて、下位レベルまたは従属クラスを提供します。 DI 原理を使用すると、これらの下位クラスをインターフェイスまたは抽象クラスに反転することができるため、テスト容易性が高く、変更が容易な結合度の低いシステムを形成できます。

ASP.NET デザイン パターン:

以上が一般的な設計原則を例とともに詳細に説明の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。