Java における OO の概念と設計原則の簡単な紹介 (コレクション)

以下のエディターでは、Java における OO の概念と 設計原則 について簡単に説明します (必読)。編集者はこれがとても良いと思ったので、参考として共有します。編集者と一緒に見に来てください

1. OO (オブジェクト指向) 設計基盤

オブジェクト指向 (OO): オブジェクトの概念に基づいており、オブジェクト中心で、クラスと継承を構築メカニズムとして使用し、インターフェイスを最大限に活用しています。 とポリモーフィズムは、客観的な世界を認識、理解、記述し、対応するソフトウェア システムを設計および構築するための柔軟性を提供します。オブジェクト指向の機能: さまざまなオブジェクト指向プログラミング言語 は互いに異なりますが、それらはすべてオブジェクト指向の基本機能

– 抽象化、今のところ詳細は考慮しないでください
– カプセル化、内部実装を隠す
– 継承、既存のコードを再利用
– ポリモーフィズム、 オブジェクトの動作を書き換える

デザインパターン: それは「優れたオブジェクト指向設計」です。いわゆる「優れたオブジェクト指向設計」とは、「変更に対応し、再利用性を向上させる」ことができる設計です。オブジェクト指向設計パターンはソフトウェア設計を記述するため、プログラミング言語には依存しませんが、オブジェクト指向設計パターンの最終実装は依然としてオブジェクト指向プログラミング言語を使用して表現する必要があります。オブジェクト指向の設計パターンは、コピーして使用できるアルゴリズム手法とは異なり、「オブジェクト指向」の熟練した深い理解に基づいた経験的な理解です。

モデル を提供します。オブジェクト指向設計パターンを習得するための前提条件は、まず「オブジェクト指向」テクノロジーを習得することです。

Ⅱ。 OO (オブジェクト指向) の設計目標

※拡張性: 新しい要件により、既存のパフォーマンスに影響を与えたり、新たな欠陥をもたらすことなく、新しいパフォーマンスをシステムに簡単に追加できます。

※変更可能性 柔軟性: システムの一部のコードが変更された場合、システムの既存の構造を破壊することはなく、他の部分にも影響を与えません。

※プラグ可能性: システム内の一部のコードは、システムに影響を与えることなく、同じインターフェースの他のクラスに置き換えることができます。

3つ。 OO 設計の 5 つの主要原則とその関係

3.1 OO 設計原則の概要

※単一責任原則:クラスに関する限り、クラスは 1 つだけあるべきです。変更の理由。独身であることはクラスにとって良い設計です。責任が混在していて不明確であると、コードが特にぎこちなく見え、全体に影響を及ぼし、美観が失われ、必然的に醜いシステムエラーが発生するリスクが生じます。

※オープンクローズ原則: は、ソフトウェアエンティティ(クラス、モジュール、関数など)は拡張可能だが変更できないことを意味します。オープンおよびクローズの原則を実現するための中心となるアイデアは、抽象化が比較的安定しているため、具体的ではなく抽象的にプログラムすることです。クラスを固定の抽象化に依存させることで、変更がクローズされ、オブジェクト指向の継承とポリモーフィズムのメカニズムを通じて、抽象クラスを継承し、そのメソッドを上書きすることで固有の動作を変更し、新しい拡張メソッドを実現できます。開いています。 「要件は常に変化しており」、不変のソフトウェアは存在しないため、ソフトウェア内のパッケージ化システムの安定性を維持し、変更の影響を受けずに、ニーズに合わせて変更をクローズするクローズド・オープン原則を使用する必要があります。要件。

※ 依存関係逆転の原則:具体性に依存せず、抽象化に依存します。抽象化の安定性がシステムの安定性を決定します。抽象化は不変であり、抽象化への依存はオブジェクト指向設計の本質であり、依存関係逆転原理の中核であるためです。抽象化に依存するのが一般原則ですが、場合によっては詳細に依存することが避けられず、抽象化と具体性の間のトレードオフを考慮する必要があり、その方法は静的ではありません。抽象化に依存するということは、実装ではなくインターフェイスをプログラミングすることを意味します。

※ リヒター置換原則: サブタイプはその親タイプで置換できなければなりません。 Liskov 置換原則は、主に継承に基づいて抽象化とポリモーフィズムを構築することに重点を置いています。したがって、Liskov 置換原則に従うことによってのみ、継承の再利用を確実に行うことができます。実装方法はインターフェイス指向プログラミングです。ExtractAbstractClassを通じてパブリック部分を基本クラスインターフェイスまたは抽象クラスに抽象化し、親クラスメソッドをオーバーライドすることでサブクラスで同じ責任をサポートする新しい方法を実装します。 。 Liskov 置換原理により、システムの優れたスケーラビリティが保証されると同時に、ポリモーフィズムに基づく抽象化メカニズムが実装され、コードの冗長性が削減され、実行時の型の区別が回避されます。

※インターフェース分離原則: 複数の顧客関連インターフェースは、1つの一般的なインターフェースよりも優れています。分離には主に 2 つの方法があります。 1. 委任の分離。クライアントのリクエストを委任するための新しいタイプを追加し、クライアントとインターフェイスの直接の依存関係を分離します。ただし、システムのオーバーヘッドが増加します。 2. 多重継承を分離し、インターフェース多重継承を通じて顧客のニーズを実現する この方法の方が優れています。

以下の 2 つの原則は、これまで言及されていませんでしたが、設計時に考慮すべき重要な原則でもあります。

※デメテルの法則: 相互に直接通信しないクラスは直接通信すべきではありません。 2 つのクラスが相互に直接通信する必要がない場合、2 つのクラスは直接対話すべきではありません。クラスがクラスのメソッドを呼び出す必要がある場合、その呼び出しはサードパーティを通じて転送できます。デメテルの法則で強調される最初の前提は、クラスの設計において、各クラスはメンバーのアクセス権を最小限に抑えるべきであるということです。その基本的な考え方は、クラス間の疎結合を強調することです。

※合成/集約再利用の原則: 可能な限り合成/集約を使用し、継承は使用しないようにしてください。構成 (Composition) と集約 (Aggregation) は特別なタイプの関連付けであり、集約は弱い所有権関係を表し、構成は部分と全体の間の厳密な関係を反映します。同じ。合成または集約の原則を優先すると、各クラスがカプセル化され、単一のタスクに集中し続けることができます。こうすることで、クラスとクラスの継承階層が小さくなり、制御不能な巨大なものに成長する可能性が低くなります

3.2 OO 設計原則間の関係1 オープンクローズ原則 (OCP) を実装する重要なステップは抽象化です。基本クラスとサブクラス間の継承関係は、抽象化を反映しています。したがって、リスコフ置換原則は、抽象化を達成するための特定の手順を仕様化したものです。リスコフ置換原則に違反することは、「オープン-クローズド」原則に違反することを意味しますが、必ずしもその逆ではありません。

2. 「オープン-クローズド」原則と依存関係逆転原則 (DIP) は、目的と手段の関係です。開閉原理が目的であれば、依存逆転原理は「開閉」原理を達成するための手段である。最適な「開始と終了」の原則を実現したい場合は、依存関係の逆転の原則を可能な限り遵守する必要があります。依存関係の逆転の原則は、「抽象化」の最適な仕様です。

3. リスコフ置換原理 (LSP) は依存性反転原理の基礎であり、依存性反転原理はリスコフ置換原理の重要な補足です。

4. インターフェース分離原則 (ISP) も、「オープン-クローズ」原則を確保するための重要な手段です。

5. 単一責任原則（SRP）については、責任が単純であればあるほど、「オープン・クローズ」とリヒター代替を達成しやすいと個人的には考えています。

4つ。 OO 設計原則と目標の関係

1. 拡張性: により、同じインターフェースを持つ新しいクラスで古いクラスを置き換えることができます。これは、抽象インターフェースの再利用です。クライアントは具象実装クラスではなく抽象インターフェイスに依存するため、クライアントに影響を与えることなくこの具象クラスを他の具象クラスに置き換えることができます。次の原則により、スケーラビリティが可能になります。 ※オープン/クローズ原則

※依存性逆転原則
※合成/集合体再利用原則

2. 変更可能性の柔軟性: モジュールは比較的独立しており、通信は最小限に抑えられます。このようにして、1 つのモジュールが変更されても、他のモジュールにはほとんど影響を与えません。

次の原則により、変更可能性が実装されます。

※オープン/クローズ原則
※デメテルの法則
※インターフェース分離原則

3. 交換プラグ可能性:部品がニーズを満たさなくなった場合、古い部品を取り外して、新しい部品を挿入できます。

次の原則により、置換可能性が実装されます。

※オープン/クローズの原則
※リヒター置換の原則
※依存性逆転の原則
※合成/集合体再利用の原則

5. OO（オブジェクト指向）設計プロセス

1. スタイルを分析し、機能を分類します。

2. 関数に基づく抽象クラス。

※ クラスの抽象化 - このステップでは、「単一責任原則」に基づいてクラスの特定の抽象化を実行できます。クラスの機能をシンプルかつ明確にするようにしてください。

※ カプセル化の変更点 – カプセル化を使用してオブジェクト間に境界層を作成することで、設計者が境界層の一方の側を、もう一方の側に悪影響を与えることなく変更できるようになり、それによって層間の疎結合が実現します。

3. 抽象基本クラスとインターフェイス クラスを設計します。

※ 基本基底クラスを抽象化してインターフェースを定義する場合、インターフェースを抽象化する際には「インターフェース分離原則」に従う必要があります。

※ インターフェースと基本クラスを設計するときは、実装ではなくインターフェースのプログラミングに常に注意を払う必要はありません。

※ 抽象基底クラスと派生クラスの間では「リヒター置換原理」の要件を満たす必要があります。

4. クラス間の結合関係を決定します。

4.1 結合度を決定するための基礎は何ですか?

※簡単に言うと、デマンドの安定性から結合度が決まります。

※ 安定性の高い要件や変更が容易ではない要件については、さまざまなタイプを完全に密結合するように設計することができます。これにより効率が向上し、より優れた技術を使用して効率を向上したりコードを簡素化することもできます。

※ 要件が変更される可能性が高い場合は、クラス間の結合の問題を十分に考慮する必要があります。結合度を下げる方法はさまざまに考えられますが、要するに、レベルを高めることに他なりません。さまざまなクラスを分離するには、この抽象化レベルを抽象クラス、具象クラス、インターフェイス、またはクラスのグループにすることができます。結合を減らす考え方を一言でまとめると、「実装のためのプログラミングではなく、インターフェースのためのプログラミングです。

※クラスの結合関係を決定する際には、「ディミッターの法則」と「合成/集合体の再利用」を考慮するようにしてください。」

4.2 依存関係の逆転を実現するにはどうすればよいですか?

※ 抽象的な方法で結合することが依存関係逆転の原理の鍵です。抽象的な結合関係には常に、抽象クラスを継承する具体的なクラスが含まれており、それらは次のことを行う必要があります。 から参照されることが保証されます 基本クラス内のどこでもそのサブクラスに変更できます。 したがって、Liskov 置換原則は依存関係逆転原則の基礎です

※ 抽象化への依存: 具象に依存しないことをお勧めします。クラス、つまりプログラム内のすべての依存関係。すべてが抽象クラスまたはインターフェイスで終了するようにしてください:

(1) 変数 は具体的なクラスへのポインターまたは参照を保持すべきではありません
(2)クラスは、具体的なクラスをオーバーライドする必要はありません。 ※ クラスの抽象化や関数が「単一責任の原則」を満たしているか
※ 継承関係や基底クラスへの参照については、「リヒター置換原則」「依存関係逆転の原則」を満たしているか

※「オープンクローズ原則」が概ね満たされているかどうか一般的にオブジェクト指向設計を行う際には、設計の5大原則を十分に考慮する必要がありますが、必須ではありません。満足の原則を盲目的に追求することは可能であり、特定の状況に応じて分析および設計できる設計されたシステムのパフォーマンスとリソースの消費につながります

以上がJava における OO の概念と設計原則の簡単な紹介 (コレクション)の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。