オブジェクト指向設計に精通した Java プログラマ向けに 10 の設計原則を詳しく解説

この記事では主に Java プログラマが知っておくべき 10 の オブジェクト指向 の設計原則を詳しく紹介します。興味のある方は参考にしてください

オブジェクト指向の設計原則は OOPS プログラミングに基づいています。私がこれまで見てきた Java プログラマーは、Singleton、Decorator、Observer などの設計パターンには熱心ですが、上記のオブジェクト指向分析と設計の学習には十分な注意を払っていません。 「抽象化」、「カプセル化」、「ポリモーフィズム」、「継承」などのオブジェクト指向プログラミングの基本を学ぶことは重要ですが、簡潔なモジュール設計を作成するには、これらの設計原則を理解することも同様に重要です。さまざまな経験レベルの Java プログラマが、これらの OOPS および SOLID 設計原則を知らないか、特定の設計原則の利点やコーディングでの使用方法さえ知らない人をよく見かけます。

(設計原則) 肝心なのは、高い凝集性と低い結合性を備えたコーディングまたは設計を常に追求することです。 Apache と Sun のオープン ソース コードは、Java と OOPS の設計原則を学ぶための良い例です。これらは、設計原則が Java プログラミングでどのように使用されるかを示しています。 Java JDK は、BorderFactory クラスのファクトリ パターン、Runtime クラスのシングルトン パターン、および java.io クラスのデコレータ パターンといったいくつかの設計原則を使用します。ちなみに、Java のコーディング原則に本当に興味がある場合は、Java API を作成した Joshua Bloch の『Effective Java』を読んでください。オブジェクト指向の設計パターンに関する私の個人的なお気に入りは、Kathy Sierra の Head First Design Pattern と、オブジェクト指向の分析と設計について簡単に説明した他の書籍です。これらの書籍は、さまざまなオブジェクト指向および SOLID 設計パターンを最大限に活用する、より優れたコードを作成するのに非常に役立ちます。

デザイン パターン (原則) を学ぶ最良の方法は、実際の例を通して、デザイン原則に違反することによって引き起こされる不都合を理解することですが、この記事の目的は、Java プログラマーにオブジェクト指向のデザインに触れたことのない人にオブジェクト指向のデザインを紹介することです。原則的には学習段階にあります。私は個人的に、OOPS と SOLID の設計原則を明確に紹介する記事が必要だと考えています。ここでできる限りのことを行うつもりですが、次の設計パターン (原則) を参照する準備をしてください :)

ドライ – 繰り返しはしないでください。

私たちの最初のオブジェクト指向設計原則は、DRY です。名前からわかるように、DRY (繰り返しをしない) は、繰り返しコードを記述するのではなく、それを再利用可能なコード ブロックに抽象化することを意味します。同一のコード ブロックが 2 つ以上ある場合は、それらを別のメソッドに抽象化するか、ハードコーディングされた値を複数回使用する場合は、それらをパブリック定数にすることを検討してください。このオブジェクト指向設計原則の利点は、メンテナンスが容易であることです。この原則を乱用しないことが重要です。重複はコードではなく機能です。これが意味するのは、共通のコードを使用して OrderID と SSN を検証したとしても、それらが同じであること、または今後も同じであることを意味するわけではないということです。共通のコードを使用して 2 つの異なる関数を実装するか、これら 2 つの異なる関数を密接に結び付けると、OrderID 形式が変更されると、SSN 検証コードが壊れます。したがって、この結合には注意し、互いに関係のない類似したコードを結合しないでください。

頻繁に変更されるコードをカプセル化する

変更内容をカプセル化する

ソフトウェア分野で決して変更されないものは「変更」なので、将来変更されると思われる、または変更されると思われるコードをカプセル化します。このオブジェクト指向設計パターンの利点は、適切にカプセル化されたコードのテストと保守が容易であることです。 Java でプログラミングしている場合は、次の原則に従ってください:

変数とメソッドのアクセス権は、デフォルトでプライベートに設定されており、それらのアクセス権は、「プライベート」から「プロテクト」、「」など、段階的に解放されます。非公開です。」 Java の一部のデザイン パターンではカプセル化が使用されます。ファクトリ デザイン パターンはその一例であり、オブジェクトを作成するコードをカプセル化し、次のような柔軟性を提供します。新しいオブジェクトのその後の生成は既存のコードに影響を与えません。 オープン/クローズ設計原則

オープンクローズ設計原則

クラス、メソッド/関数は拡張機能 (新しい関数) に対してオープンであり、変更に対してクローズである必要があります。これは、テストに合格したコードが誰かに変更されるのを防ぐ、もう 1 つのエレガントな SOLID 設計原則です。理想的には、新しい機能を追加した場合、コードがテストされることになります。これがオン/オフ設計原則の目標です。ちなみに、SOLIDの「O」はオープン/クローズの設計原理を表しています。

単一責任原則

単一責任原則(SRP)

単一責任原則も SOLID 設計原則の 1 つであり、SOLID の文字「S」はそれを指します。 SRP によれば、クラス変更の理由は 1 つだけである必要があり、そうでない場合、クラスは常に 1 つの関数を実装する必要があります。 Java のクラスが複数の関数を実装している場合、これらの関数間に結合関係が作成されます。関数の 1 つを変更すると結合関係が壊れ、新たな問題を回避するために別のラウンド テストが行​​われる可能性があります。

依存性の注入または反転の原則

依存性の注入または反転の原則

フレームワークの依存性注入機能がどのようなメリットをもたらすかは尋ねないでください。依存性注入機能は、Spring フレームワークの実装ですでに十分に利用可能です。この設計原則の優雅さは、オブジェクトを作成するコードがフレームワーク内で集中化され、クライアント コードから分離されているため、DI フレームワークによって挿入されたクラスはモック オブジェクトでテストしやすく、保守も容易であることです。依存関係注入を実装するには、バイトコード ツール、ポイントカット式や Spring で使用されるプロキシなどの一部の AOP (アスペクト指向プログラミング) フレームワークの使用など、さまざまな方法があります。この SOLID 設計原則の詳細については、IOC および DI 設計パターンの例を参照してください。 SOLID の文字「D」は、この設計原則を表しています。

継承よりも合成を優先する

継承よりも合成を優先する

可能であれば、継承よりも合成を優先します。これについて異論を唱える人もいるかもしれませんが、私は合成のほうが継承よりも柔軟性があると考えています。合成では、プロパティを設定することで実行時にクラスの動作を変更できます。ポリモーフィズムを使用すると、クラス間の合成関係をインターフェイスの形式で実装し、合成関係を柔軟に変更できます。 Effects Java でも、継承ではなく合成を使用することを推奨しています。

リスコフ置換原理

リスコフ置換原理LSP

リスコフ置換原理によれば、親クラスが出現する箇所は、例えば、親クラスのメソッドや、関数はサブクラス オブジェクトに置き換えられます。 LSP は、単一責任原則およびインターフェイス分離原則と密接に関連しています。親クラスがその子クラスよりも多くの機能を備えている場合、その機能はサポートされず、LSP 設計原則に違反する可能性があります。 LSP SOLID 設計原則に従うためには、派生クラスまたはサブクラス (親クラスと比較して) の機能を削減するのではなく、機能を強化する必要があります。 SOLID の文字「L」は、LSP 設計原則を指します。

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

インターフェース分離原則とは、インターフェースの機能が必要ない場合は、このインターフェースを実装しないことを意味します。これは主に、インターフェイスに複数の関数が含まれているが、実装クラスに必要なのはそのうちの 1 つだけである場合に発生します。インターフェイスの設計は、一度インターフェイスを公開すると、それを実装するクラスに影響を与えずに変更することはできないため、難しい作業です。 Java におけるこの設計原則のもう 1 つの利点は、インターフェイスには、クラスが使用する前にインターフェイスのすべてのメソッドを実装する必要があるという特性があるため、単一関数のインターフェイスを使用すると、実装するメソッドの数が少なくなるということです。

プログラミングは(実装オブジェクトではなく)インターフェースを中心とします

プログラミングは常に(実装オブジェクトではなく)インターフェースを中心とするため、コード構造が柔軟になり、新しいインターフェース実装オブジェクトは既存のコード構造と互換性があります。したがって、Java では、変数、メソッドの戻り値、メソッドのパラメーターの

データ型にはインターフェイスを使用してください。これは多くの Java プログラマーのアドバイスであり、Effective Java や head first design pattern などの本のアドバイスでもあります。

エージェンシー原則

1 つのクラスがすべての機能を完了することを期待しないでください。実装のために一部の機能をプロキシ クラスに適切に委任することができます。プロキシ原理の例は、Java の equals() メソッドと hashCode() メソッドです。 2 つのオブジェクトの内容が同じかどうかを比較するには、呼び出し元ではなく比較クラス自体に比較作業を実行させます。この設計原則の利点は、コーディングの重複がなく、クラスの動作を簡単に変更できることです。

概要

上記のオブジェクト指向設計原則はすべて、柔軟でエレガントなコード、つまり凝集性が高く結合性が低いコード構造を作成するのに役立ちます。理論は最初のステップにすぎません。これらの設計原則をいつ使用するかを発見する能力を獲得することがより重要です。設計原則に違反していないか、コードの柔軟性に影響を与えていないかを確認するためですが、問題を解決するときに常に設計パターンと設計原則を使用できるわけではありません。これらは主にメンテナンス サイクルが長いプロジェクトに使用されます。大規模なエンタープライズ プロジェクト。

以上がオブジェクト指向設計に精通した Java プログラマ向けに 10 の設計原則を詳しく解説の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。