10の一般的なデザインパターン、一度にインタビューに合格できる（gitbuhプロジェクト：AlgorithmPractice）

プロジェクト紹介

• このプロジェクトは、主要な工場の一般的な筆記面接の質問を分解し、データ構造とアルゴリズムの基礎となる実装原理までソースをたどり、それらが何であるかを知っています。
• 簡単な検索のための知識構造システムを確立し、志を同じくする友人をプロジェクトAlgorithmPracticeに参加するように歓迎します（問題とプルリクエストは歓迎されます）。

10の一般的なデザインパターン：

• 1. シングルトンシングルトンモード
• 2. プロキシモード
• 3. 戦略戦略モード
• 4. オブザーバーオブザーバーモード
• 5. 訪問者訪問者モード
• 6、工場工場モード
• 7. 委任委任モード
• 8. プロトタイププロトタイプモード
• 9、テンプレートテンプレートモード
• 10. アダプターモード
• 11.その他のデザインパターンについては、私のgithubのデザインパターンセクションに直接アクセスして確認してください。非常に熟練していることに感謝し、私に注目してください！

テキストの始まり

1.シングルトンシングルトンモード

• コードの実装：シングルトン
• デザインのアイデア：
  • 一部のシナリオでは、インスタンス化オブジェクトを1つだけ提供するクラスが必要なため、クラスのコンストラクターをprivateにします。
  • プライベート後にこのクラスのオブジェクトを取得するにはどうすればよいですか？外部にgetInstance関数を提供して、プライベートオブジェクトを出力します。
  • では、このプライベートオブジェクトはどこから来たのでしょうか。最初にクラスでオブジェクトを定義し、次にgetInstance関数を介してそれを返す場合、それを空腹マンモードと呼びます（空腹すぎるため、すべての食べ物/インスタンスは私を待つために新しくなければなりません）。最初に定義されていたが、後で使用される場合、getInstance関数で新しく戻り、それはレイジーマンモードになります。
  • 空腹の男モードと怠惰な男モードがあるのはなぜですか？空腹マンモードとレイジーマンモードの違いは、新しいオブジェクトが新しいときです。新しいオブジェクトは、リソースと時間を消費するプロセスであることがわかっています。特に、頻繁にロードされる非常に大きなオブジェクトとネストされたオブジェクトの場合、メモリをスケジュールして割り当てるにはCPUが必要です。これは非常に遅く、実際に使用するときにロードすると、時間を節約できます。
  • それで、私は怠惰な人モードを使うべきですか？いいえ、レイジーマンモードは適切に使用されません。セキュリティの問題が発生し、複数のオブジェクトが表示されます。これは、シングルトンモードの本来の意図に違反し、さらにスレッドの安全性の問題を引き起こします。
  • では、安全性を確保するためにどのように使用できますか？これは同期ロックによって保証されますが、ロックによってパフォーマンスが低下します。この損失が減少し、操作が安全な場合はどうなりますか？DCLSingletomの紹介ですが、DCLSingletomは必ずしも安全ですか？命令の並び替えにより、オブジェクトを使用する際にエラーが発生する可能性があります（オブジェクトの属性値がnull）。
  • より良い提案？列挙と内部疲労を使用して、シングルトンモードを実装します。
• 注：
  • 同期を使用する場合は、揮発性と連携して命令の再配置を禁止することを忘れないでください。

2.プロキシモード

• コードの実装：プロキシ
• デザインのアイデア：
  • エージェンシーモデルの出現は、主に開発言語の継承と書き換えの特性に基づいています。
  • プロキシモードは、実際の実行クラスの前後にいくつかの従来の操作を追加するものです。誰もが使用するいくつかのパブリックメソッド。統合例外処理、統合ログ、統合エラーリターンなどの一般的なアプリケーションはすべて、プロキシモードを使用して、実行クラスはビジネス自体にのみ関連し、他の状況を過度に考慮することはありません。
  • コード表示：
• プロキシインターフェース、プロキシクラス、プロキシクラスはすべてそれを実装し、そのメソッドをオーバーライドする必要があります。

public interface ProxyInterface {
    
    
    void work();
}

• プロキシクラス

public class Proxy implements ProxyInterface {
    
    
    ProxyInterface p;
    public Proxy(ProxyInterface r) {
    
    
        // TODO Auto-generated constructor stub
        p = r;
    }
    @Override
    public void work() {
    
    
        // TODO Auto-generated method stub
        System.out.println("i am Proxy, i am help real's work,work begin");
        p.work();
        System.out.println("i am Proxy, work end");
    }
}

• 実際の実行クラス

public class Real implements ProxyInterface {
    
    

    @Override
    public void work() {
    
    
        // TODO Auto-generated method stub
        System.out.println("i am real, i am doing work");
    }
}

• 効果を達成する

public class ProxyTest {
    
    

    @Test
    public void testProxy(){
    
    
        ProxyInterface r = new Real();
        ProxyInterface p = new Proxy(r);
        p.work();
    }
}

• 注：
  • 設計では、プロキシクラスはプロキシクラス以上のものを考慮する必要があります。

3.戦略戦略モード

• コードの実装：戦略
• デザインのアイデア：
  • 戦略モードは、実際にはエージェントモードとほぼ同じであり、1つのレイヤーをパッケージ化した後に表示されます。
  • しかし、エージェントはクラスの書き換えを使用し、戦略は実際にパッケージを使用します、笑
  • この戦略では、クラスをコンテナとして使用して実際のクラスをパッケージ化し、統一されたメソッドを使用してラップされたクラスを呼び出します。
  • ポリシーコンテナーとポリシーインターフェイスは、プロキシクラスとプロキシインターフェイスとは関係ありません。
  • コード
• ポリシーインターフェース

public interface Strategy {
    
    
    void method();
}

• 戦略1

public class strategy01 implements Strategy {
    
    
    @Override
    public void method() {
    
    
        // TODO Auto-generated method stub
        System.out.println("strategy01's method.");
    }
}

• 戦略2

public class strategy02 implements Strategy {
    
    
    @Override
    public void method() {
    
    
        // TODO Auto-generated method stub
        System.out.println("strategy02's method.");
    }
}

• 戦略コンテナ

public class StrategyMethod {
    
    
    Strategy strategy;
    public StrategyMethod(Strategy strategy) {
    
    
        this.strategy = strategy;
    }
    public void opera() {
    
    
        strategy.method();
    }
}

• 実際の効果

public class StrategyTest {
    
    
    @Test
    public void tetsStrategy(){
    
    
        Strategy s1 = new strategy01();
        Strategy s2 = new strategy02();
        StrategyMethod sm1 = new StrategyMethod(s1);
        sm1.opera();
        StrategyMethod sm2 = new StrategyMethod(s2);
        sm2.opera();
    }
}

• 注：

4.オブザーバーオブザーバーモード

• コードの実装：オブザーバー
• デザインのアイデア：
  • オブザーバーモードは、ゲーム内の目に相当し、オブザーバーのメソッドにアイを挿入し、オブザーバーのメソッドを実行すると、オブザーバーが情報を受け取り、レスポンスメソッドを起動します。
  • したがって、完全なオブザーバーモデルには、オブザーバーとオブザーバーが含まれます。
  • オブザーバーには、オブザーバーをロードするための特別なメソッドと、オブザーバーに通知するための別のメソッドが必要です
  • したがって、オブザーバーには、オブザーバーのトリガーを待機するコールバックメソッドも必要です。
  • コード
• 観察者

public class ObserverDemo {
    
    
    String name;
    public ObserverDemo(String name) {
    
    
        this.name = name;
    }
    public void lister() {
    
    
        System.out.println(name + " --> 观察到异常，并采取行动");
    }
}

• 観察された

public class ObservableDemo {
    
    
    List<ObserverDemo> list = new ArrayList<>();
    public void attach(ObserverDemo observerDemo) {
    
    
        list.add(observerDemo);
    }
    public void normalaction() {
    
    
        System.out.println("ObservableDemo normalaction:普通方法不会引起观察 ");
    }
    public void action() {
    
    
        System.out.println("ObservableDemo action：特殊方法会引起观察");
        notification();
    }
    public void notification() {
    
    
        for (ObserverDemo o : list) {
    
    
            o.lister();
        }
    }
}

• 効果を達成する

public class ObserverTest {
    
    
    @Test
    public void Testobserer(){
    
    

        //被观察者
        ObservableDemo observableDemo = new ObservableDemo();
        //观察者
        ObserverDemo observerDemo1 = new ObserverDemo("observerDemo1");
        ObserverDemo observerDemo2 = new ObserverDemo("observerDemo2");
        //被观察者将观察者加入自己的方法内
        observableDemo.attach(observerDemo1);
        observableDemo.attach(observerDemo2);
        //被观察者触发某个方法
        observableDemo.action();
        System.out.println("-----------------");
        observableDemo.normalaction();

    }
}

ObservableDemo action：特殊方法会引起观察
observerDemo1 --> 观察到异常，并采取行动
observerDemo2 --> 观察到异常，并采取行动
-----------------
ObservableDemo normalaction:普通方法不会引起观察 

• 注：

5.訪問者訪問者モード

• コードの実装：訪問者
• デザインのアイデア：
• 注：

6、工場工場モード

• コードの実装：ファクトリー
• デザインのアイデア：
• 注：

7.委任委任モード

• コードの実装：
• デザインのアイデア：
• 注：

8.プロトタイププロトタイプモード

• コードの実装：
• デザインのアイデア：
• 注：

9、テンプレートテンプレートモード

• コードの実装：テンプレート
• デザインのアイデア：
  • テンプレートデザインパターンの本質は、固定アルゴリズムフレームワークです。
  • 親クラスには固定テンプレートがありますが、開いているテンプレートの特定の実装手順により、サブクラスで書き直すことができます
  • コード
• お父さん

public abstract class TemplateDemo {
    
    
    public final void template() {
    
    
        method1();
        method2();
        method3();
    }
    public void method1() {
    
    
        System.out.println("father class first stop");
    }
    public void method2() {
    
    
        System.out.println("father class second stop");
    }
    public void method3() {
    
    
        System.out.println("father class third stop");
    }
}

• サブクラス

public class SubTemplate extends TemplateDemo {
    
    
    @Override
    public void method1() {
    
    
        System.out.println("sub class first step");
    }
}

• 成し遂げる

public class TemplateTest {
    
    
    SubTemplate subTemplate = new SubTemplate();
    @Test
    public void testTemplate() {
    
    
        subTemplate.template();
    }
}

• 注：
  • 一般的なテンプレートデザインパターンはチェーンプログラミングで実装されます

10.アダプターモード

• コードの実装：アダプター
• デザインのアイデア：
• 注：