この記事では、主にスプリングフレームワークの骨構造の設計概念を分析します。これらのコンポーネントがこれらのコンポーネントを必要とするのはなぜですか？それらはどのように結合してSpringの骨格建築を形成しますか？ SpringのAOP機能は、これらの基本的な骨格アーキテクチャをどのように使用して機能しますか？このデザインを完了するために、春にどのようなデザインモデルが使用されますか？このデザインコンセプトの将来のソフトウェアデザインのインスピレーションは何ですか？この記事では、これらの質問に詳細に答えます。
春の骨格建築
春には12個以上のコンポーネントがありますが、以下の実際のコンポーネントはいくつかあります。
図1。Thespringフレームワークの全体的なアーキテクチャ図
上記の図から、スプリングフレームワークにはコア、コンテキスト、豆という3つのコアコンポーネントしかないことがわかります。彼らは春の骨格建築全体を構築します。それらがなければ、AOPやWebなどの上層の特性を持つことは不可能です。以下は、主にこれら3つのコンポーネントから春を分析します。
春のデザインコンセプト
前述のように、スプリングの3つのコアコンポーネントが導入されています。 Beanは春の本当の主人公です。
Beanの春の役割は、OPの概念のようなものです。パフォーマンス段階のように、しかし俳優はいません。なぜ春には春のデザインの目標があるのですか？彼の依存関係噴射メカニズムである構成ファイルを管理します。そして、この注入関係はIOC容器で管理されており、IOC容器のオブジェクトは何がBeanによって包まれています。 Springは、これらのオブジェクトを管理する目的であり、Beanにオブジェクトを梱包することにより、追加の操作を追加する目的です。
その設計戦略は、もちろん、Javaの設計コンセプトに完全に似ています。特定のルールに従って、この環境のこの環境。それについて考えて、私たちが大規模な同様のデザインコンセプトで使用する他のフレームワークについて考えてください。
コアコンポーネントと協力する方法
前述のように、Beanは春の重要な要素です。あなたがパフォーマンスの俳優である場合、コンテキストはこのパフォーマンスの段階的な背景であり、コアはパフォーマンスの小道具でなければなりません。彼らが一緒にいるときだけ、彼らは良いショーを行うことができる最も基本的な状態を持つことができます。もちろん、最も基本的な条件はこのパフォーマンスを際立たせることはできません。彼が演奏するショーは、春が提供できる特徴的な機能です。
Beanはオブジェクトであり、オブジェクトがこのデータを提供する方法が、コンテキストの間の問題を発見し、この関係を構築したいと考えています。彼らとこの関係を維持するため。したがって、コンテキストは、このIOCコンテナが確立されると、この関係のコレクションも同様です。では、コアコンポーネントの使用は何ですか？実際、コアは、各豆を発見、確立、および各豆間の関係を維持するために必要ないくつかの列です。
以下の図で表すことができます。
図2。3つのコンポーネント関係
コアコンポーネントの詳細な説明
ここでは、各コンポーネントの階層的な関係を詳細に紹介し、実行時に順序を注文します。春の使用に注意を払う必要があります。
Beanコンポーネント
Beanコンポーネントの春の重要性は、以前に説明されています。 Beanコンポーネントは、Springのorg.springframework.beansの下にパッケージ化されています。このパッケージの下のすべてのカテゴリは、Beanの定義、Beanの作成、およびBeanの分析の3つのことを解決します。春のユーザーにとって、思いやりが必要なのは、他の2つが内部で行われることです。
Springbeanの典型的な工場モデルが作成されました。
図4。TheBeanFactoryの相続関係
BeanFactoryには、ListableBeanFactory、HierarchicalBeanFactory、Autowire有能なBean Factoryの3つのサブクラスがあります。ただし、上記の図から、最終的なデフォルトの実装クラスはDefaultListableBeanFactoryであることがわかり、彼はすべてのインターフェイスを実装しています。では、なぜこれほど多くのレベルのインターフェイスを定義するのでしょうか？これらのインターフェイスのソースコードと指示を確認してください。操作プロセス。たとえば、ListableBeanFactoryインターフェイスは、これらの豆がリスト可能であることを示しており、HierarchicalBeanFactoryは、これらの豆が相続関係を持っていることを意味します。 AutoWirecapableBeanFactoryインターフェイスは、Beanの自動アセンブリルールを定義します。これらの4つのインターフェイスは、豆のコレクション、豆の関係、および豆の動作を共同で定義します。
Beanの定義には、主にBeanDefinitionの説明が含まれています。
図5。Bybeanを定義したクラスの階層関係図
Beanの定義は、さまざまなサブノードを含むSpringの構成ファイルで定義したノード内のすべての情報の完全な説明です。 Springが定義したノードを正常に分析したとき、彼は春以内にビアンデフニッションオブジェクトに変換されました。すべての操作は、将来このオブジェクトに対して行われます。
Beanの分析プロセスは非常に複雑であり、ここには拡張すべき多くの場所があり、可能な変更に対処するのに十分な柔軟性を確保する必要があるため、機能は詳細に分割されています。 Beanの分析は、主にSpring構成ファイルを分析することです。この分析プロセスは、主に以下の図のクラスを通じて完了しています。
図6.ビーンの分析クラス
もちろん、ここには具体的な分析もあります。
コンテキストコンポーネント
コンテキストは、spring.springframework.contextの下でパッケージ化されています。この環境の構築方法を見てみましょう。
ApplicationContextは、アプリケーション環境の基本情報に加えて、コンテキストの最上位のクラスです。以下は、コンテキストの構造図です。
図7.コンテキスト関連のクラス構造図
上の図から、アプリケーションのコンテストがBeanFactoryを継承していることがわかります。
ApplicationContextのサブクラスには、主に2つの側面が含まれています。
configurableapplicationContextは、コンテキストが変更されていることを示しています。つまり、ユーザーは、コンテキストの下に複数のサブクラスを追加または変更できます。
WebApplicationContextは、通常、ServiceContextに直接アクセスできるコンテキストです。
次に、サブダウンは、コンテキストのタイプを構築し、その後にコンテキストにアクセスする方法が続きます。このような最初のレベルレベルは、完全なコンテキストレベルレベルを構成します。
一般に、ApplicationContextは以下を完了する必要があります。
◆アプリケーション環境を作成します
◆BeanFactoryを使用して、Beanオブジェクトを作成します
◆オブジェクト関係テーブルを保存します
◆さまざまなイベントをキャプチャできます
Spring IOCコンテナとして、コンテキストは基本的にSpringの機能のほとんどを統合するか、ほとんどの機能の基礎です。
コアコンポーネント
コアコンポーネントは、Springのコアコンポーネントとして、重要なコンポーネントの1つがリソースへのアクセス方法を定義することです。すべてのリソースをインターフェイスに抽象化するこの方法は、将来のデザインで学ぶ価値があります。春のこの部分の役割を見てみましょう。
以下の図は、関連するリソースに関連する構造図です。
図8.ルソース関連のクラス構造図
上の図から、リソースインターフェイスがさまざまな可能なリソースタイプをカプセル化すること、つまり、ファイルタイプの違いがユーザーにとってブロックされていることがわかります。リソースのプロバイダーでは、リソースを使用する方法も問題です。このようにして、すべてのリソースはinputstreamクラスを通じて取得できるため、リソースのプロバイダーもシールドされます。もう1つの問題は、リソースのロードの問題、つまり、上記の図からすべてのリソースをロードできることです。
コンテキストとリソースがどのように関係を確立したかを見てみましょう。最初に彼らの関係の図を見てください：
図9。コンテキストとリソースの関係図
上記の図から見られるように、コンテキストは、リソースのロード、分析、およびResourcePatterNresolverクラスに同等のものを委ねます。コアコンポーネントには多くの同様の方法があります。
IOCコンテナでの作業方法
前述のように、コアコンポーネント、ビーンコンポーネント、コンテキストコンポーネントの相互依存性があります。
BeanFactory Factoryの作成方法
図2で説明するように、IOCコンテナは実際には他の2つのコンポーネントを組み合わせたBean関係ネットワークです。ビルドインエントランスは、AbstractApplicationContextクラスの更新方法です。この方法のコードは次のとおりです。
リスト1.AbstractApplicationContext.Refresh
Public void Refresh（）は、synchronized（this.startupshutdownmonitor）を投げますコンテキスト（BeanFactory）を使用します。 Bean Processors（BeanFactory）を登録しますSubclasses（）。 catch（beansexter ex）は、リソースを避けるために作成されたシングルトンを破壊します。
この方法は、IOCコンテナプロセス全体の完全なコードを構築し、内部の各コード行が基本的にほとんどの春の原則と機能を理解していることを理解することです。
このコードには主にそのような手順が含まれています。
◆BeanFactoryを順番に構築します
◆イベントは登録に興味があるかもしれません
◆Beanインスタンスオブジェクトを作成します
◆聞いているイベントのトリガー
以下に、これらのプロセスのコード分析と組み合わされています。
2番目と3番目の文は、BeanFactoryを作成および構成することです。これは、前述のように、更新されたサブクラスです。以下は、BeanFactoryを更新するためのメソッドコードです。
リスト2
Protected beansexception {hasbeanfactory（）; ;同期（this.beanfactorymonitor）{this.beanfactory = beanfactory;} catch（ioexception ex）{show new applicationContextexcexce Ption（ "i/o error＆nbsp;この方法は、AbstractApplicationContextの抽象的な方法をrefressbeanFactoryに実現します。 BeanFactoryオブジェクトの種類には、さまざまな種類のオブジェクトがあることに注意してください。 BeanFactoryの元のオブジェクトは、このクラスの継承レベルの図を見てみましょう。
図10. DeFaultListableBeanFactoryクラス継承図
BeanFactory関連クラスに加えて、Beanの登録にも関連していることがわかりました。 refressbeanFactoryメソッドでは、この方法を見つけるLoadBeanDefinitions（BeanFactory）があります。コンテナ。
このプロセスは、次のシーケンシャルマップで説明できます。
図11。BeanFactoryの時間序文を作成します
Beanの分析と登録プロセスは次のとおりです。
イチジク
BeanFactoryを作成した後、Spring自体に必要なツールクラスを追加します。
AbstractApplicationContextの次の3つのラインコードは、Springの関数の拡大に重要な役割を果たします。最初の2行は、主にBeanFactoryの構成の構成を変更できます。したがって、それらはすべてスプリングの機能を拡張するため、スプリングを使用することのこの部分を使用することを学ぶ必要があります。
その中で、InvokeBeanFactoryPostProcessorsメソッドでは、主にBeanFactoryPostProcessorインターフェイスを実装するためのサブクラスを取得することです。 PostProcessBeanFactoryメソッドを実行すると、この方法のステートメントは次のとおりです。
リスト3.beanfactorypostprocessor.postprocessbeanfactory
void postprocessbeanfactory（configureablelistablebeanFactory BeanFactory）はBeanSexceptionをスローします。
そのパラメーターは、BeanFactoryによって変更できることを示しています。データは自由に変更します。
RegisterBeanPostProcessorsメソッドは、BeanPostProcessorインターフェイスのユーザー定義のサブクラスを取得し、それらをBeanFactoryオブジェクトのBeanPostProcessors変数に実行することもできます。 2つの方法は、beanpostprocessorで宣言されています。ポストプロセスベーフルイニタレイズとポストプロセッアフテリニル化は、Beanオブジェクトの初期化中に実行するために使用されます。ユーザー定義の操作を実行できます。
後期線コードは、監視イベントの初期化の登録であり、リスナーはアプリケーションのリスナーでなければなりません。
Beanインスタンスを作成し、Beanの関係ネットワークを構築する方法
以下は、finishbeanfactoryInitityメソッドから始まるインスタンス化された豆のコードです。
リスト4.AbstractApplicationContext.finishBeanFactoryInitialization
保護されたfinishbeanfactableは、タイプマッチングのためにTempossloaderを使用することを停止します。 Lazy-Init）BeanFactory。
BeanのインスタンスがBeanFactoryにあることがわかります。 PreintantiateSinglettonsメソッドのコードは次のとおりです。
リスト5.DefaultListableBeanFactory.PreinstantialSinglettons
public void preinstantiateSingletons（）はbeansexception {if（this.logger.isinfoenabled（））{this.logger.info（ "instantiating singletons in";}同期（this.beandefinitionmap）{for（for：this：this：this：this：this： beandefinitionNames）{rootbeandefinition bd = getMergedlocalbeandefinition（beanname）; iseagerinit; if（system.getSecurityManager（）！= null &&; factory of smartfactorybean）{isea gerinit = accesscontroller.dopriviledege iiseagerinit（）; ;}}}}}}}}}ここには非常に重要な豆があります。 GetObjectメソッドが実装されている限り、インスタンスオブジェクトを生成する方法を定義できます。ただし、Spring内のこの豆のインスタンスオブジェクトは、ObjectのGetObjectメソッドを呼び出すことにより、ユーザーのカスタマイズされたオブジェクトを取得することができます。 SpringのFactoryBean自体を取得するオブジェクトは、完了して完了します。
Beanのインスタンスオブジェクトを作成する方法と、Beanインスタンスオブジェクト間の関連する関係にコアキーを構築する方法は、このプロセスのフローチャートです。
図13.ビーンインスタンスの作成フローチャート
それが普通の豆である場合、彼はgetBeanメソッドを呼び出すことにより、彼のインスタンスを直接作成します。以下は、Beanインスタンスを作成する時間のマップです。
図14.ビーンインスタンスの作成シーケンシャルチャート
もう1つの非常に重要な部分は、Beanオブジェクトインスタンス間の関係を確立することです。
図15.ビーンオブジェクト関係の確立
IOCコンテナの拡張点
もう1つの問題は、これらの豆オブジェクトを特定の拡張性にする方法、つまり一部の操作を追加する方法です。では、拡張機能は何ですか？ Springはこれらの拡張機能をどのように呼びますか？
SpringのIOCコンテナには、非常に多くあります。 BeanFactoryPostProcessor、BeanPostProcessor。それらは、BeanFactoryを構築し、Beanオブジェクトを構築するときに呼ばれます。 Beanインスタンスによって作成されて破壊されたときに、beanとDosusebeanが初期化されています。ユーザーはこれらのインターフェイスで定義されたメソッドを実装でき、Springは適切な時期に呼び出します。もう1つはFactoryBeanです。彼は特別な豆です。
これらの拡張ポイントは、通常、特定のタスクを完了するために、スプリングの拡張機能とそれらの使用方法を知る方法によって異なります。 。次の比phorを使用して説明できます。
IOCコンテナを1つのボールに比較してください。それに対応する関係は、BeanFactoryがマシン作成モデルであり、ボールモードはBean、ボールオブザボールモードはBeanのインスタンスです。前述の拡張機能はどこにありますか？ BeanFactoryPostProcessorはボールモデルの作成に対応しており、それを修正する機会があります。つまり、彼はあなたがボールモードを変更するのを助けることができます。 InitializingBeanとDosuseableBeanは、ボールモデルの最初と終わりにあり、準備と尾部作業を完了することができます。 BeanPostProcessorを使用すると、ボールモードに適切な修正を行うことができます。最後に、魔法のボールモデルであるファクトリベンがあります。このボールモードは事前にはありませんが、このボールモデルの形状を決定できるので、彼が作成したボールはあなたが望むボールでなければなりません。あなたが望むボール
私のためにIOCコンテナを使用する方法
スプリングコンテナの建設プロセスの以前の導入、春は私たちのために何ができるか、そして春のIOCコンテナは何ができるか？最初にスプリングを使用してIOCコンテナを構築する必要があります。ApplicatonContext.xmlは、IOCコンテナのデフォルト構成ファイルです。
IOCは、実際にあなたのために骨格のアーキテクチャを設定しています。では、どのように参加しますか？これは、春にいくつかの拡張機能を理解するために先に言ったことであり、これらの拡張ポイントを達成することで春の共通の動作を変えます。私たちが望む人格の結果を得るための拡張ポイントを達成する方法に関しては、春には多くの例があります。参照に使用されます。
春のAOP機能の詳細な説明
動的プロキシの実装の原則
SpringのAOPを理解するには、AOPが動的プロキシに基づいて実装されているため、動的機関の原則を最初に理解する必要があります。動的エージェントは、JDK自体から開始する必要があります。
JDKのJava.lang.Refletパッケージの下には、代理店クラスの入り口であるプロキシクラスがあります。このクラスの構造：
図16.プロキシ構造構造
上の写真から、4つはパブリックメソッドです。最後の方法NewProxyInstanceは、プロキシオブジェクトを作成する方法です。このメソッドのソースコードは次のとおりです。
リスト6.Proxy.NewProxyInstance
public staticオブジェクトNewProxyInstance（クラスローダーローダー、クラス> []インターフェース、Invocatchhandler H）は、if（h == null）{th row nullpointerexception（）;} class cl = getproxyclass（loader、interfaces）; = cl.getConstructor（constructorparams）; ）;} catch（instantiationException e）{throw new Internet（e.toString（））;} catch new Internet（e.toString（））;}}}この方法には、プロキシクラスローダークラスとエージェントクラスが同じローダークラスをロードするために使用されるクラスローダーの3つのパラメーターが必要です。インターフェイスは、表現するインターフェイスです。 InvocationHandlerは、プロキシインターフェイスのメソッドに加えて、ユーザーがカスタマイズするユーザーの操作を実行するために使用されます。ユーザーは、ターゲットメソッドを呼び出します。InvacationHandlerクラスの呼び出しで定義されている一意のメソッドで表されます。これについては、後で詳しく説明します。
プロキシがどのようにプロキシクラスを作成しているかを見てみましょう。以下に明らかになります。
図17。プロキシオブジェクトを作成します
実際、上記の図から、エージェントクラスがプロキシゲネレーターの生成プロキシクラスの方法にあることを見つけることができます。 Proxygientorクラスはsun.miscの下に包まれています。
次のようなインターフェイスがある場合：
リスト7。SimpleProxyクラス
public Interface SimpleProxy {public void sizemethod1（）;エージェントによって生成されたクラス構造は次のとおりです。
リスト8。$ proxy2クラス
Public Class 2は、java.rang.lang.lang.lang.refllect.method m1;方法M3;
このクラスのメソッドは、Invoke InvocationHandlerを呼び出し、各メソッドはプロパティ変数に対応します。これがエージェント全体の実現方法です。
Springaopを達成する方法
前のエージェントの原則から、プロキシの目的は、ターゲットメソッドが呼び出されたときに、呼び出しハンドラークラスの呼び出しメソッドを実行できることであることを知っています。 。
SpringのAOP実装は、AOP Allianceに準拠するための合意です。同時に、Springはそれを拡張し、PointCutやAdvisorなどのいくつかのインターフェイスを追加して、柔軟性を高めました。
以下は、JDKダイナミックプロキシのクラス図です。
図18.JDKダイナミックプロキシクラス図
上の写真は、AOP Allianceの定義によって定義されたインターフェイスを明確に示しています。 SpringがAOP Allianceを拡張する方法については、Springがエージェントクラスを実現する方法を見てみましょう。
リスト9。プロキシBeanを構成します
<bean id = "testbeansingleton"> <プロパティ名= "proxyinterfaces"> <value> org.springframework.ap.framework.protopettests $ testbean value> p roperty> <property " > Ref>プロパティ> <プロパティ名= "Singleton"> <value> trueValue> Property> <Property name = "interceptors"> <list> <value> testInterceptorValue> <val ue> testInterceptor2Value> list> bean>
構成では、エージェントのインターフェイスが設定されていることを確認し、インターフェイスの実装クラスがターゲットクラスであり、ターゲットメソッドを実行する前にインターセプターが呼び出されます。エッセンス
Springがエージェントをどのように完成させ、インターセプターを呼び出す方法を見てみましょう。
前述のように、Spring AOPは、このプロキシクラスを完成させる独自の拡張ポイントも実現しています。もちろん、プロキシオブジェクトは、プロキシクラスを通じて動的に生成する必要があります。
以下は、春までに作成されたプロキシオブジェクトのタイミングチャートです。
図19。オブジェクトオブジェクトの出現
Springがプロキシオブジェクトを作成した後、ターゲットオブジェクトのメソッドを呼び出すと、前述のInvocationHandlerクラスのInvokeメソッドに表されます。ここでは、JDKDynamicaopproxyクラスがInvocationHandlerインターフェイスを実装しています。
Springがインターセプターをどのように呼ぶかを見てみましょう。
図20.スプリングはインターセプターを呼び出します
上記は、JDKダイナミックエージェントもCLIBエージェントをサポートしています。
春の設計モード分析
また、工場モード、シングルモード、テンプレートモードなど、「WebXフレームワークのシステムアーキテクチャとデザインモデル」、「Tomcatのシステムアーキテクチャ、モード設計分析」など、春に使用される多くのデザインパターンもあります。すでに紹介されています。ここでは、主に代理店モードと戦略モードを導入します。
プロキシモード
プロキシモードの原則
プロキシモードは、特定のオブジェクトのプロキシオブジェクトを作成し、プロキシオブジェクトは元のオブジェクトへの参照を制御し、このプロキシオブジェクトの作成は元のオブジェクトに追加の操作を追加できます。以下は、プロキシモードの構造です。
図21。プロキシモードの構造
件名：抽象的なテーマは、もちろん、エージェントオブジェクトの実際のオブジェクトを実現するためのインターフェイスです。
ProxySubject：抽象テーマの定義のインターフェイスに加えて、プロキシクラスはエージェントオブジェクトの参照も保持する必要があります
RealSubject：エージェントのクラスはターゲットオブジェクトです。
春にプロキシモードを実装する方法
Spring AOPのJDKダイナミックエージェントは、エージェンシーモードテクノロジーを使用することで達成されます。春のプロキシオブジェクトのインターフェイスに加えて、org.springframework.aop.springproxyおよびorg.springframework.apork.adviseもあります。春にプロキシモードを使用するコンストラクターは次のとおりです。
図22。プロキシモードの構造図は、配線で使用されます
$ proxyは作成されたプロキシオブジェクトであり、件名は抽象的なテーマであり、プロキシオブジェクトは、InvocationHandlerを介してターゲットオブジェクトへの参照を保持することです。
春の実際のプロキシオブジェクト構造は次のとおりです。
リスト10プロキシオブジェクト$ proxy4
パブリッククラス$ proxy4は、java.lang.refllect.proxyを実装しています。springframework.ap.framework.protopettests$ testbean work.aop.springproxy org.springframework.aop.framework.advend反省method.lang.lang.lang.lang.lang.lang.method.method M12; .reflect.method m11; java.lang.reflect.method m22; java.lang.reflect.Method m3; java.lang.reflect.Method java.lang.reflect. Method m4; java.lang.reflet.method m19; java .lang.reflect.Method M7; java.lang.reflet.method m15; java.lang.reflet.method m20; left.Method M10; java. LANG.Reflect.Method M1; java.lang.reflect.Method M17; java .lang.reflect.Method M21; java.lang.reflect.Method m0; ava.lang.reflet.method m24; int HashCode (); int indexof (org.SpringFramework.aop.advisor); int interxof (org.aopalliance. aip.advice); ject); java.lang.string tostring (); void sayhello (); void dosomething (); void dosometHing2 (); java.lang.class getProxiedIndIndIndIndIndIndIRFACES (); ProxytargetClass (); Org.SpringFramework.aop .advisor; getadvisors (); void addvisor (int, org.springframework.aip.advisor) Throws org.SpringFramework.aP.framework.aPConfigeXception; void addadvisor (ORG.Sprin gframework.aop.advisor) Throws org.SpringFramework.aop. framework.aPConfigeXception; void SetTargetsource (ORG .springframework.aop.targetsource); ORG.SpringFramework.aop.Targetsource GetTARGETSource (); d (); Boolean IsinterfaceProxied (java.lang.class); Boolean Removeadvisor (org.SpringFramework.aP. advisor );; Boolean SOR, ORG.SpringFramework.aP.Advisor) Throws org.SpringFramework.aop.framework.aPConfigeXception; void addAdvice (ORG.AOPALLIANCE.AOP.ADVICE) Throws org.SpringFramework.aP.framework.aPConfigexception; void addvice (int, org.aopalliance.aop.advic e) Throws org.Springframework.aP.framework.aPConfigeXception; .aop.advice); java.lang.string toproxyconfigstring (); Boolean isfrozen (); void setexposeProxy (Boolean);
戦略モード
策略模式原理
The strategy model, as the name suggests, is a strategy to do something. This usually means that there may be multiple methods to complete a certain operation in programming. These methods may have different occasions and may have different adaptation. However, these methods may使用されます。各一个操作方法都当作一个实现策略，使用者可能根据需要选择合适的策略。
下面是策略模式的结构：
图23.策略模式的结构
Context：使用不同策略的环境，它可以根据自身的条件选择不同的策略实现类来完成所要的操作。它持有一个策略实例的引用。创建具体策略对象的方法也可以由他完成。
◆Strategy：抽象策略，定义每个策略都要实现的策略方法
◆ConcreteStrategy：具体策略实现类，实现抽象策略中定义的策略方法
◆Spring中策略模式的实现
◆Spring中策略模式使用有多个地方，如Bean定义对象的创建以及代理对象的创建等。这里主要看一下代理对象创建的策略模式的实现。
前面已经了解Spring的代理方式有两个Jdk动态代理和CGLIB代理。这两个代理方式的使用正是使用了策略模式。它的结构图如下所示：
图24.Spring中策略模式结构图
在上面结构图中与标准的策略模式结构稍微有点不同，这里抽象策略是AopProxy接口，Cglib2AopProxy和JdkDynamicAopProxy分别代表两种策略的实现方式，ProxyFactoryBean就是代表Context角色，它根据条件选择使用Jdk代理方式还是CGLIB方式，而另外三个类主要是来负责创建具体策略对象，ProxyFactoryBean是通过依赖的方法来关联具体策略对象的，它是通过调用策略对象的getProxy (ClassLoaderclassLoader)方法来完成操作。
要約します
本文通过从Spring的几个核心组件入手，试图找出构建Spring框架的骨骼架构，进而分析Spring在设计的一些设计理念，是否从中找出一些好的设计思想，对我们以后程序设计能提供一些思路エッセンス接着再详细分析了Spring中是如何实现这些理念的，以及在设计模式上是如何使用的。