Java の 23 の設計パターンと 6 つの主要な設計パターン原則の概要

Java の 23 のデザイン パターンの分析

1. デザイン パターンの概要

一般に、デザイン パターンは 3 つのカテゴリに分類されます:

合計 5 つのタイプ: ファクトリ メソッド パターン、抽象ファクトリ パターン、シングルトン パターン、ビルダー パターン、プロトタイプ パターン。

アダプター モード、デコレーター モード、プロキシ モード、アピアランス モード、ブリッジ モード、コンビネーション モード、およびフライウェイト モードの合計 7 つの構造モードがあります。

行動パターン、合計 11: 戦略パターン、テンプレートメソッドパターン、オブザーバーパターン、反復サブパターン、責任連鎖パターン、コマンドパターン、メモパターン、状態パターン、訪問者パターン、仲介パターン、インタープリターパターン。

詳細は次のとおりです:

作成タイプは次のとおりです:

1. シングルトン、シングルトン モード: クラスのインスタンスが 1 つだけであることを確認し、そのインスタンスへのグローバル アクセスを提供します

ポイント

2抽象ファクトリ、抽象ファクトリ: 具体的なクラスを指定せずに、一連の関連オブジェクトまたは相互依存オブジェクトを作成するためのインターフェイスを提供します。

3. ファクトリ メソッド: オブジェクトを作成するためのインターフェイスを定義し、どのクラスをインスタンス化するかをサブクラスに決定させます。ファクトリ メソッドは、サブクラスへのクラスのインスタンス化を遅らせます。

4. ビルダー、構築モード: 複雑なオブジェクトの構築をその表現から分離し、同じ構築プロセスで異なる表現を作成できるようにします。

5. プロトタイプ、プロトタイプ モード: プロトタイプ インスタンスを使用して、作成するオブジェクトのタイプを指定し、これらのプロトタイプをコピーして新しいオブジェクトを作成します。

動作タイプは次のとおりです:

6. イテレータ、イテレータ パターン: オブジェクトの内部表現を公開せずに、集合オブジェクトの各要素に順次アクセスするメソッドを提供します。

7. オブザーバー、オブザーバー パターン: オブジェクト間の 1 対多の依存関係を定義します。オブジェクトのステータスが変化すると、それに依存するすべてのオブジェクトが通知され、自動的に更新されます。

8. TemplateMethod: 動作中のアルゴリズムのスケルトンを定義し、一部のステップをサブクラスに延期します。TemplateMethod を使用すると、アルゴリズムの構造を変更せずにアルゴリズムを再定義できます。

9. コマンド、コマンド モード: リクエストをオブジェクトとしてカプセル化し、さまざまなリクエストで顧客をパラメータ化し、リクエストをキューに入れ、リクエスト ログを記録し、取り消し可能な操作をサポートできます。

10. 状態、状態モード: 内部状態が変化したときにオブジェクトの動作を変更できるようにします。オブジェクトのクラスが変更されたようです。

11. 戦略、戦略パターン: 一連のアルゴリズムを定義し、それらを 1 つずつカプセル化して、アルゴリズムを使用する顧客から独立させます。

12. China of Responsibility、責任連鎖モデル: 複数のオブジェクトにリクエストを処理する機会を与え、それによってリクエストの送信者と受信者の間の結合関係を回避します

13. Mediator Interpreter パターン: 仲介者の使用オブジェクトを使用して、一連のオブジェクトの対話をカプセル化します。

14. ビジターモード: オブジェクト構造内の各要素に作用する操作を表します。各要素のクラスを変更せずに、この要素に作用する新しい操作を定義できます。

15. インタプリタ、インタプリタモード: 言語を指定して、その文法の表現を定義し、この表現を使用して言語文を解釈するインタプリタを定義します。

16. Memento、メモモード: オブジェクトの内部状態をキャプチャし、オブジェクトを破壊せずにこの状態をオブジェクトの外部に保存します。

構造タイプは次のとおりです:

Seventeen、コンポジット、結合モード: オブジェクトをツリー構造に結合して、部分と全体の関係を表現すると、ユーザーは単一のオブジェクトと結合されたオブジェクトを一貫して使用できます。

18. ファサード、外観モード: サブシステム内の一連のインターフェイスに一貫したインターフェイスを提供します。これにより、サブシステムが使いやすくなります。

19. プロキシ、プロキシ モード: このオブジェクトへのアクセスを制御するために他のオブジェクトにプロキシを提供します

20. アダプター、アダプター モード: あるタイプのインターフェイスを顧客が望む別のタイプに変換します インターフェイス、アダプター パターン互換性のないインターフェイスのために連携できないクラスが連携できるようになります。

21. デコレータ、デコレーション モード: オブジェクトに追加の役割を動的に追加します。追加機能の点では、デコレータ モードはサブクラスを生成するよりも柔軟です。

22、ブリッジ、ブリッジ パターン: 抽象部分を実装部分から分離し、独立して変更できるようにします。

23歳、フライ級、フライ級モード

実際には、並行モードとスレッド プール モードの 2 つのカテゴリがあります。画像を使用して全体を説明します。

2. デザイン パターンの 6 つの原則

一般原則: オープン クローズの原則

オープン アンド クローズの原則は、拡張と拡張にオープンであることを意味します。拡張に対するオープンは閉じられています。プログラムを拡張する必要がある場合、元のコードを変更することはできませんが、ホットスワップ可能な効果を実現するには、元のコードを拡張する必要があります。つまり、プログラムをスケーラブルにし、保守とアップグレードを容易にするためです。この効果を実現するには、インターフェイスや抽象クラスなどを使用する必要があります。これについては、後の具体的な設計で説明します。

1. 単一責任の原則

クラス変更の理由が 1 つだけであってはなりません。つまり、各クラスは単一の責任を実装する必要があります。そうでない場合は、クラスを分割する必要があります。

2. リスコフ置換原則

リスコフ置換原則 LSP (リスコフ置換原則 LSP) は、オブジェクト指向設計の基本原則の 1 つです。リスコフ置換原則には、次のとおりです。 LSP は継承と再利用の基礎です。派生クラスが基本クラスを置き換えることができ、ソフトウェア ユニットの機能が影響を受けない場合にのみ、基本クラスが真に再利用され、派生クラスも再利用されます。新しい動作は、基本クラスに基づいて追加できます。リスコフ置換原則は、「オープン-クローズ」原則を実現するための重要なステップです。つまり、リスコフの置換原則は、抽象化を実現するための特定の手順の仕様です。Baidu

百科事典より

歴史的な置換原則では、サブクラスは親クラスのメソッドを上書きしたり書き換えたりしないように努めるべきです。親クラスは定義された構造を表し、この標準化されたインターフェイスを通じて外部と対話するため、サブクラスはそれを無造作に破壊してはなりません

3. 依存関係の逆転の原則

これは、開始および終了の原則の基礎です、具体的な内容: インターフェイス。指向プログラミングは、具象性ではなく抽象化に依存します。コードを記述するとき、具象クラスと対話するのではなく、具象クラスの上位レベルのインターフェイスと対話します。 4. インターフェイス分離原則 )

この原則は次のことを意味します。各インターフェースには、サブクラスによって使用されないメソッドはありませんが、実装する必要がある場合は、インターフェースを分割して、複数の分離されたインターフェース (複数のインターフェース・メソッドを 1 つに結合したインターフェース) を使用することをお勧めします。

5. デメテル原則 (デメテル原則)

つまり、依存するクラスについての知識が少ないほど良いということです。つまり、依存するクラスがどれほど複雑であっても、ロジックは適切である必要があります。メソッド内にカプセル化され、パブリック メソッドを通じて外部に提供されるため、依存クラスが変更された場合、そのクラスはそれをほとんど認識しません。つまり、直接の友人とのみ通信することになります。クラス間の結合関係は、フレンド関係と呼ばれます。結合は、依存関係、関連性、集約、組み合わせなどに分けられます。メソッドのパラメータとメソッドの戻り値内のクラスは、直接のフレンドではありません。

6. 複合再利用の原則 )

原則は、Java A の 23 の設計パターンです。 . 作成パターン

このセクションからは、Java の 23 のデザイン パターンについて、概念、適用シナリオなどを詳しく紹介し、デザイン パターンの特徴と原則に基づいて分析します。

まず、シンプルファクトリパターンは、23に関わるパターンには属しません。 シンプルファクトリは、一般に、通常のシンプルファクトリ、マルチメソッドシンプルファクトリ、静的メソッドシンプルファクトリに分けられます。

0. シンプルファクトリモード

シンプルファクトリモードは次の3種類に分かれています: 01. 通常の

は、同じインターフェースを実装するいくつかのクラスのインスタンスを作成するファクトリクラスを確立します。まず、関係図を見てください:

例: (電子メールとテキスト メッセージの送信の例を示します) まず、この 2 つの間の共通インターフェイスを作成します:

public interface Sender {
    public void Send();
}

次に、実装クラスを作成します:

public class MailSender implements Sender {
    @Override
    public void Send() {
    System.out.println("this is mailsender!");
    }
}

public class SmsSender implements Sender {
    @Override
    public void Send() {
    System.out.println("this is sms sender!");
    }
}

最後に、ファクトリ クラスを構築します:

public class SendFactory {
    public Sender  produce(String type){
    if ("mail" .equals(type) {
        return new MailSender( );
    }else if("sms" .equals(type)){
        return new SmsSender();
    }else{
        System. out . println("请输入正确的类型！"); 
        return null;)
    }
}

テストしましょう:

public class FactoryTest {
    public static void main(String[] args) {
        SendFactory factory = new SendFactory();
        Sender sender = factory.produce("sms");
        sender.Send();
    }
}

出力: this is sms sender!

02. 複数のメソッド

は、通常のファクトリ メソッド パターンの改良です。文字列にエラーがある場合、オブジェクトは正しく作成できません。複数のファクトリ メソッド パターンでは、オブジェクトを個別に作成するための複数のファクトリ メソッドが提供されます。関係図:

上記のコードを修正し、SendFactoryクラスを次のように変更します:

public class SendFactory {
    public Sender produceMail(){
        return new MailSender();   
    }        
    public Sender produceSms(){
        return new SmsSender();
    }
}

テストクラスは次のとおりです:

public class FactoryTest{
    public static void main(String[] args) {
        SendFactory factory = new SendFactory( );
        Sender sender = factory.produceMail();
        sender.Send();
    }
}

出力: this is mailsender!

関連記事:

Java デザイン パターン - デザイン パターンの 6 つの原則

Java の 24 のデザイン パターンと 7 つの原則

以上がJava の 23 の設計パターンと 6 つの主要な設計パターン原則の概要の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。