Java デザイン パターンの概要

この要約は主に、デザイン パターンの基本に関する以前の一連の記事に基づいています。重要な知識点を自分の言葉で説明することがメインですが、間違いがあるかもしれませんが、ご容赦いただき、ご指導いただければ幸いです。

#デザイン パターン

クリエイティブ パターン

クリエーション パターンの役割は作成ですオブジェクトの作成に関して、最もよく知られているのは、新しいオブジェクトを作成して、関連するプロパティを設定することです。ただし、多くのシナリオでは、特にクラスを定義して他の開発者に提供する必要がある場合、オブジェクトを作成するためのより使いやすい方法をクライアントに提供する必要があります。

単一インスタンス

单例模式保证全局的单例类只有一个实例，这样的话使用的时候直接获取即可，比如数据库的一个连接，Spring里的bean，都可以是单例的。

单例模式一般有5种写法。

第一种是饿汉模式，先把单例进行实例化，获取的时候通过静态方法直接获取即可。缺点是类加载后就完成了类的实例化，浪费部分空间。

第二种是饱汉模式，先把单例置为null，然后通过静态方法获取单例时再进行实例化，但是可能有多线程同时进行实例化，会出现并发问题。

第三种是逐步改进的方法，一开始可以用synchronized关键字进行同步，但是开销太大，而后改成使用volatile修饰单例，然后通过一次检查判断单例是否已初始化，如果未初始化就使用synchronized代码块，再次检查单例防止在这期间被初始化，而后才真正进行初始化。

第四种是使用静态内部类来实现，静态内部类只在被使用的时候才进行初始化，所以在内部类中进行单例的实例化，只有用到的时候才会运行实例化代码。然后外部类再通过静态方法返回静态内部类的单例即可。

第五种是枚举类，枚举类的底层实现其实也是内部类。枚举类确保每个类对象在全局是唯一的。所以保证它是单例，这个方法是最简单的。

ファクトリ パターン

简单工厂一般是用一个工厂创建多个类的实例。

工厂模式一般是指一个工厂服务一个接口，为这个接口的实现类进行实例化

抽象工厂模式是指一个工厂服务于一个产品族，一个产品族可能包含多个接口，接口又会包含多个实现类，通过一个工厂就可以把这些绑定在一起，非常方便。

プロトタイプ パターン

一般通过一个实例进行克隆从而获得更多同一原型的实例。使用实例的clone方法即可完成。

ビルダー パターン

建造者模式中有一个概念叫做链式调用，链式调用为一个类的实例化提供便利，一般提供系列的方法进行实例化，实际上就是将set方法改造一下，将原本返回为空的set方法改为返回this实例，从而实现链式调用。

建造者模式在此基础上加入了builder方法，提供给外部进行调用，同样使用链式调用来完成参数注入。

構造パターン

前の作成パターンでは、オブジェクトを作成するためのいくつかの設計パターンが紹介されました。このセクションで紹介される構造はパターンです。コード構造を変更することで分離を実現し、コードの保守と拡張を容易にすることを目的としています。

アダプター パターン

アダプター パターンは、2 つの異なるクラスを適応させるために使用されます。

アダプター モードとプロキシ モードの類似点と相違点

これら 2 つのモードを比較することは、実際にはオブジェクト アダプター モードとプロキシ モードを比較することになります。コード構造の観点から見ると、

これらは非常に異なります。いずれも特定の実装クラスのインスタンスを必要とします。

しかし、それらの目的は異なります。プロキシ モードは、元のメソッドを強化する作業を行います。

アダプターは、「チキンをアヒルにパッケージングし、次に使用します」を提供するために、適応の作業を行います。それはアヒルです」、

ニワトリとアヒルの間には継承関係はありません。

アダプター パターンは、クラス アダプター、オブジェクト アダプターなどに分類できます。

クラス アダプターは、親クラスを継承することによって、親クラスに自身を適応させることができます。

オブジェクト アダプターは、パッケージ化のためにオブジェクトを別のオブジェクトのコンストラクターに渡す必要があります。

フライウェイト モード

/ フライウェイト モードの中核は、フライウェイト ファクトリ クラスにあります。

// フライウェイト ファクトリ クラスの機能は次のとおりです。フライウェイト オブジェクトの保存に使用されるフライウェイト プールを提供するには、

// ユーザーがオブジェクトを必要とする場合、まずフライウェイト プールからオブジェクトを取得します。

// フライウェイト プールにオブジェクトが存在しない場合は、プール、作成します。 新しいフライウェイト オブジェクトがユーザーに返されます。

// 新しいオブジェクトをフライウェイト プールに保存します。

//Flyweight Pattern

// 英語は Flyweight Pattern です。誰が最初にこの言葉を訳したのか分かりません。非常にわかりにくい翻訳だと感じます。接続バー。フライウェイトとは軽量という意味です。フライウェイトとは共有コンポーネント、つまり既に生成されたオブジェクトを再利用することを指します。このアプローチは当然軽量です。

// オブジェクトを再利用する最も簡単な方法は、HashMap を使用して新しく生成された各オブジェクトを保存することです。オブジェクトが必要になるたびに、まず HashMap にアクセスしてオブジェクトが存在するかどうかを確認し、存在しない場合は新しいオブジェクトを生成して、このオブジェクトを HashMap に追加します。

// この単純なコードのデモは行いません。

エージェント モード

// そのようなものは存在しないことがわかりました。端的に言えば、プロキシ モードは「メソッドのパッケージ化」または「メソッドの拡張」を行うことです。 」。

// アスペクト指向プログラミングでは、この用語は忘れてください。AOP では、

// は実際には動的プロキシのプロセスです。たとえば、Spring では、

// プロキシ クラスを自分で定義しませんが、Spring はプロキシ

// を動的に定義し、@Before、@ で定義するのに役立ちます。その後、@Around のコード ロジックがエージェントに動的に追加されます。

外観モード

外観モードは通常、特定の実装の詳細をカプセル化し、よりシンプルなインターフェイスをユーザーに提供します。

必要なコンテンツはメソッド呼び出しを通じて取得できます。

結合モード

//結合モードは、データを階層構造で表現するために使用され、単一オブジェクトと結合オブジェクトへのアクセスが一貫したものになります。

//直接例を見てみましょう。各従業員には、名前、部門、給与などの属性があります。

// 部下の従業員のコレクションもあります (ただし、コレクションはempty),

// 部下の従業員は自分の従業員と同じ構造を持ちます。

// 名前や部署などの属性も持ちます。

// 彼らはまた、部下の従業員のコレクションを持っています。

class Employee {
    private String name;
    private String dept;
    private int salary;
    private List<Employee> subordinates; // 下属
}

Decorator パターン

Decorator

Decorator パターンは、最上位の親クラスから各拡張クラスを継承します。機能拡張が必要な​​場合は、クラス インスタンスを拡張クラスに渡すだけで、拡張クラスを使用するときに元のクラスの機能を拡張できます。

プロキシ モードとは異なり、デコレータ モードでは、各デコレーション クラスは親クラスを継承し、複数のレベルでカプセル化できます。

動作パターン

動作パターンは、さまざまなクラス間の相互作用に焦点を当て、責任を明確に分割し、コードをより明確にします。

戦略モード

戦略モードは通常、戦略をクラスとして扱い、戦略を指定する必要がある場合にインスタンスを渡します。これにより、アルゴリズムを使用できるようになります。ここで、指定されたアルゴリズムを渡します。

コマンドモード

コマンド モードは通常、コマンドの開始者、コマンド、およびコマンドの受信者の 3 つの役割に分かれています。

コマンド イニシエーターは、使用時にコマンド インスタンスを挿入する必要があります。次に、コマンド呼び出しを実行します。

コマンド呼び出しは、実際にコマンド受信者のメソッドを呼び出して実際の呼び出しを行います。

たとえば、リモコンのボタンはコマンドに相当し、ボタンをクリックするとコマンドが実行され、テレビが提供するメソッドが自動的に呼び出されます。

テンプレート メソッド パターン

テンプレート メソッドとは、一般に、いくつかの実装クラスといくつかの抽象クラスを含み、実行順序を指定するメソッド テンプレートを提供することを指します。

実装クラスは、テンプレートによって提供される優れたメソッドです。抽象クラスはユーザーが自分で実装する必要があります。

テンプレート メソッドは、テンプレート内のメソッドの実行順序を指定します。これは一部の開発フレームワークに非常に適しているため、テンプレート メソッドはオープン ソース フレームワークでも広く使用されています。

オブザーバー パターンとイベント リスニング メカニズム

オブザーバー パターンは、通常、サブスクライバーとメッセージ パブリッシャー間のデータ サブスクリプションに使用されます。

一般に、オブザーバーとトピックに分けられ、オブザーバーはトピックをサブスクライブし、トピックによって維持されるオブザーバー リストにインスタンスを登録します。

トピックがデータを更新すると、自動的にデータをオブザーバーにプッシュするか、データが更新されたことをオブザーバーに通知します。

しかし、この方法により、メッセージプッシュの結合関係は比較的密になります。そして、データを開かない限り、データ型が何であるかを知ることは困難です。

データ形式をより柔軟にするために、イベント パターンとイベント リスナー パターンが使用されていることは知っていますが、イベントによってラップされたイベント タイプとイベント データは、サブジェクトとオブザーバーから分離されました。

トピック イベントが発生すると、イベントのすべてのリスナーがトリガーされ、イベントはリスナー リストを通じて各リスナーに送信されます。イベントをリッスンした後、まずイベントに応じて対応するイベント タイプを見つけます。サポートするイベント ハンドラーを入力し、そのハンドラーを使用して対応するイベントを処理します。

責任チェーン モデル

責任チェーンは通常、最初に一方向のリンク リストを確立する必要があります。その後、呼び出し元はヘッド ノードを呼び出すだけで済みます。後ほど自動で流れます。例えば、プロセスの承認が好例で、エンドユーザーが申請を提出するだけで、申請の内容情報に基づいて自動的に責任連鎖が確立され、フローが開始されます。

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