シングルトン
Singletonパターンは、クラスのインスタンスが1つだけ可能
メソッドのインスタンスを作成することを選択した
負荷に（この瞬間はロードする必要が使用されていない）1.
他のすべての場所を用いて、本実施例で使用される
場合に初めて使用負荷2
に問題マルチスレッド、そのインスタンスを確実にするためにダブルロック機構を使用するだけでよいです。
3.デュアルロック機構
/ **
*シングルトンがロックデュアルデモ
*
* /
public class DoubleCheckLock {
private static DoubleCheckLock instance ;
private DoubleCheckLock(){
}
public static DoubleCheckLock getInstance(){
if(instance == null){
synchronized (DoubleCheckLock.class) {
if(instance == null)
instance = new DoubleCheckLock() ;
}
}
return instance;
}
}ロックを動作させる必要がない場合のgetInstance最初の方法は、（インスタンス== NULL）場合、{}効率のために、直接戻すことができます。
このメソッドを使用するだけで1つのスレッドで複数のスレッドに同期されます。2つのスレッドによるロック機構の存在のために、この時点で同時に到着が存在する場合、最初のスレッドがロック文ブロックに入り、新しいシングルトン（）ステートメントを実行する最初のスレッドは、次の場合に滑らかな新しいDoubleCheckLock（）を実行してもよいです、ロックされた領域を終了します、この時間は、2番目のスレッドがロックブロックを入力することができます。
方法のgetInstance秒（インスタンス== NULL）場合、{}第二のスレッドがロック文ブロックが最初のインスタンスまたはスレッドの初期化ではないに入ることを保証することです。新しいの実装では。完全な具体化が、第2のスレッドに最初のスレッドがリアルタイムでインスタンス化インスタンスを取得できませんでした、またはnullインスタンスの判決が再びインスタンス化されるときには、このスレッドが問題になります。この時点では、インスタンスvolatileキーワードの定義に追加する必要があります。
参考記事
http://www.cnblogs.com/yanfengfree/p/6271359.html
http://blog.csdn.net/nyist327/article/details/49301401
4.実際のシーン
利点：
例では、単一の実施の形態1、得られたすべてのクラスのシングルトンインスタンスの単一の実施形態だけのインスタンスの活性は同じです。この防止他の目的は、全てのオブジェクトのインスタンスへのアクセス権があることを保証するために、自身のインスタンス化
2.一定の柔軟性を有する単一モードの実施形態を、延伸工程における対応する変化に基づいて制御プロセスをインスタンス化するそれらのクラスは、インスタンス化されセックス。
3.唯一のインスタンスへのアクセス制御を提供します。
4. 1つのオブジェクトのみがシステムメモリ内に存在するので、しばしば単一の実施形態のモードで作成され、破壊されたオブジェクトが、間違いなく、システムのパフォーマンスを改善する場合、システムリソースを節約することが可能です。
5.インスタンスの数が可変できるようにします。
6.共有リソースの複数の割り当てを避けてください。
短所：
1.オブジェクトのバリエーションの同じタイプは、常に異なるユースケースのシナリオで発生した場合は、件名を変更するのではなく、単一の場合は、誤ったデータが別の状態で保存することができない原因になります。
これシングルトンクラスを拡張していない単利モデル抽象化レイヤ以来2は、大きな困難を持っています。
ある程度の「単一責任の原則」に反する重すぎるシングルトンクラスの3機能、。
4.虐待シングルトンは、シングルトンクラスのデザインなどのデータベース接続プールオブジェクトなどのリソースを節約するために、いくつかの否定的な問題をもたらす過度の共有オブジェクトの接続プール接続プール・プログラムはオーバーフローを表示さにつながる可能性があり、インスタンス化されたオブジェクト場合使用されずに長い時間が、システムは、オブジェクトの状態が失われる、ごみを収集することができると考えられます。
注意：
あなたがそうでなければ、それは新しいオブジェクトのインスタンス化します、使用するように反射モード1の単一のケースを作成することはできません
怠惰なシングルトンを使用する場合は、スレッドの安全性の問題2に注意を払うを
シングルトンパターン工法シングルトン3.空腹と怠惰そう継承することができない、プライベートであり、シングルモードの場合も継承することができる（例えば、レジスタベースモード）
http://www.cnblogs.com/damsoft/p/6105122.html
Observerパターン
観察者（）と観察者（およびそれ以上）の間の関係、および
関係する1観察者（加入）が観察されます。
2.視聴者は、リフレッシュ動作が行われ、通知すべての観測によって（サブスクリプション）
3観察（フィード）は、各操作に対応する行いました。
4（観察され、サブスクリプションを取り消します）
：効果オブザーバパターンは、以下の利点を有する
観察と観察者との間に結合された第一、抽象モデル確立オブザーバ。オブザーバーの唯一の特定のリスト、既知の観察者の役割、各観察者が、特定の抽象オブザーバインタフェースを満たしているのです。オブザーバーは、彼らが共通のインタフェースを持っていることを知っている、いずれかの特定のオブザーバーを知りません。
彼らはさまざまな抽象化レベルに属することができるように、視聴者が密接に、一緒に結合され、視聴されていませんので。
第二に、通信をブロードキャストオブザーバーモードをサポート。観察者は登録されているすべてのオブザーバーに通知します。
オブザーバーモードでは、次のような欠点があります
観測されたオブジェクトが、直接および間接的な観察者の多くを持っている場合、最初は、それはすべてのオブザーバーは多くの時間を費やす必要が通知されます。
第二には、観測者の間で循環依存がある場合、観察者は、システムがクラッシュする原因と、それらの間の循環への呼び出しをトリガします。Observerパターンを使用して、この時点に特別な注意を払うことです。
観察者が別のスレッドによって、その後の非同期配信を、通知された場合には第三には、システムは、配信が自己矛盾的であることを確認する必要があります。（理解していない）
第四に、オブザーバーパターンは常にオブジェクト観測された変化の閲覧者に認識させることができますが、視聴者が監視対象のオブジェクトを変更が起こるかであることを知っているので、メカニズムのオブザーバーパターンはないが。
Mediatorパターン
同様の機能を媒介
Mediatorパターンは、道にこれらのオブジェクトは明らかに参照を持っていないことをお互いにそうと対話する一連のオブジェクトをラップします。彼らはより緩やかに結合することができるようになっています。
これらのオブジェクト内の特定のオブジェクト間の相互作用が変更されると、それはすぐに他のオブジェクトの数との間の相互作用には影響しません。互いに独立して、これらの相互作用を変化させることができることを保証するために
1、メディエータモードの利点は：
適切なメディエーター静的モードの（1）の使用は、メディエーターが特定のクラスをより簡単に再利用することが可能であるように、少数の継承を使用することができます。
（2）使用して、適切なカップリングメディエーターモード遷移は、メディエーター媒介クラスとクラスは比較的独立して進化することができるように、同僚の間で回避することができます。
オブジェクト間の関係を容易に維持することが対話すること（3）メディエータモード多くの多相互、そのような理解しました。
（4）オブジェクトと連携抽象化のメディエーターモード動作、他のオブジェクトとの相互作用を処理する目的は、小規模の動作で分離しました。
2、Mediatorパターンの欠点は：
（1）Mediatorパターンは、オブジェクトの同僚の複雑さ、増加した複雑性メディエータークラスの費用を減少させます。もちろん、多くの場合、何よりも優れメディエーターが良好設定メディエーターない設定する
ことが多い（2）媒介クラスを同僚の各特定のタイプの間のハーモ関係を充填し、そのようなコードは、多くの場合、再利用可能ではありません。そのため、非再利用可能な再利用は、価格のため、特定の同僚とメディエータークラスのカテゴリです。
使用Mediatorパターン一見時間がかかる元の構造よりも、しかし、イニシエータとエグゼキュータのニーズとの間のプット強い結合を大幅に内部システム・メンテナンスを最適化する、減少しました。
外観モデルは、システム間の結合を低減しつつメディエーターは、システム内の結合モードを減少させます。
システム内のクラスとクラスの間の強い結合のためのメディエーターより詳細なモデルが解除され、外観がより統合モードであり、外部接続のための全体システムが解除され、遮蔽効果の複雑さを持っている両方とも。
コールが互いにAメディエータークラスに組み込ま種々間メディエーターであることが、理解（メディエータまたは単純になり、クリア、メディエータクラスがますます複雑になります）
プロキシモード
1.帯電防止剤
の説明を与えるために、以下の場合：
アクション・セーブアナログ、保全アクションインターフェースの定義：IUserDao.java、その後、対象のオブジェクトが実装は、このインターフェイスのメソッドUserDao.java、あなたは静的なプロキシモードを使用する場合は、この時点で、あなたはエージェントに必要呼プロキシオブジェクトのメソッド呼び出しを介して、ターゲットオブジェクトを起動するタイミングオブジェクト（UserDaoProxy.java）もIUserDaoインタフェースを実現した。
プロキシオブジェクトとターゲットオブジェクトは、その後、同じインタフェースを実装し、同じメソッドを呼び出すことによって呼び出すことに留意すべきですオブジェクトの
/ **
*インタフェース
* /
パブリックインターフェイスIUserDao {
void save();
}
/ **
*インタフェース
*ターゲットオブジェクト
* /
publicクラスUserDao実装IUserDao {
公共空保存（）{
System.out.printlnはは（ " -データが保存された- ！"）;
}
}
/ **
*プロキシオブジェクト帯電防止剤
* /
publicクラスUserDaoProxy実装IUserDao {
//受信観客保存
プライベートIUserDao目標;
公共UserDaoProxy（IUserDaoターゲット）{
this.target =ターゲット;
}
public void save() {
System.out.println("开始事务...");
target.save();//执行目标对象的方法
System.out.println("提交事务...");
}
}
1.ターゲット拡張機能は、ターゲット・オブジェクトを変更することなく機能で行うことができる。
2.短所：
プロキシオブジェクトは、同時にあまりにも多くのターゲットオブジェクトと同じインタフェース、および非常に多くのプロキシクラス、クラスを実装する必要があるため。ターゲット・オブジェクトとプロキシオブジェクトを増大させるためのインターフェイスメソッドが維持されなければなら一度。
帯電防止剤の欠点を解決する方法？答えは、ダイナミックプロキシモードを使用することです
2 JDKの動的プロキシインタフェースエージェント
のInvocationHandlerインタフェース達成する
たとえば、Proxy.newProxyInstanceスルーは、動的メモリ内のプロキシオブジェクトを構築
http://rejoy.iteye.com/blog/1627405
3.Cglibエージェントは
、しかし、いくつかのクラスがインタフェースを実装していない場合、あなたはJDKプロキシを使用することはできません、JDKの動的プロキシインタフェースに依存し、動的プロキシCGLIBを使用する必要があります。（JDK源が決定インターフェースを達成していない）
対象オブジェクトサブクラス剤を達成するために、時間ベースの方法で使用することができるが、このメソッドが呼び出され：CGLIB剤、また、メモリサブに内蔵されたサブクラス剤と呼ばれますクラスは、ターゲットオブジェクトの機能の拡張を実現するために、オブジェクト。
方法：
1。CGLIB jarファイルを導入する必要がありますが、春のコアは、パッケージCGLIB機能に含まれている、春・コア-3.2.5.jarに直接導入
機能パッケージの導入後2、メモリが可能動的にサブクラスの構築
、それ以外の場合はエラー3.演技のクラスは、最終的にはできませんが
、ターゲットオブジェクトのメソッドは、ターゲットオブジェクトが追加のビジネスメソッドを実行しないこと、それが傍受されることはありません、最後の/静的な場合4.。
AOPを春にプログラミング：
インタフェースの実装はJDKプロキシを使用して、存在する場合、コンテナに対象物
対象物がCGLIB剤とのインタフェースを実装していない場合
/**
* 目标对象,没有实现任何接口
*/
public class UserDao {
public void save() {
System.out.println("----已经保存数据!----");
}
}
/**
* Cglib子类代理工厂
* 对UserDao在内存中动态构建一个子类对象
*/
public class ProxyFactory implements MethodInterceptor{
//维护目标对象
private Object target;
public ProxyFactory(Object target) {
this.target = target;
}
//给目标对象创建一个代理对象
public Object getProxyInstance(){
//1.工具类
Enhancer en = new Enhancer();
//2.设置父类
en.setSuperclass(target.getClass());
//3.设置回调函数
en.setCallback(this);
//4.创建子类(代理对象)
return en.create();
}
@Override
public Object intercept(Object obj, Method method, Object[] args, MethodProxy proxy) throws Throwable {
System.out.println("开始事务...");
//执行目标对象的方法
Object returnValue = method.invoke(target, args);
System.out.println("提交事务...");
return returnValue;
}
}Chain of Responsibilityパターン
まず、テイク責任はなく、隣の家への責任：責任モデルの純粋なチェーンは、特定のハンドラオブジェクトが2つのだけの行為のいずれかを選択することができますが必要です。特定のハンドラオブジェクトの状況は、責任の一部を負担して、許可されていない責任を伝承します。
純粋な内部要求が一つのオブジェクトによって処理されなければならない責任のパターンのチェーンは、受信され、不純な責任のパターンのチェーン内の、要求は、最終的には、任意の受信側オブジェクトによって受信されなくてもよいです。
責任パターンの純粋なチェーンの具体例としては、一般的に責任のパターンの不純なチェーンを達成するために見られている例を見つけることは困難です。一部の人々は、これが正当であってもよいし、責任の不純なチェーンは、Chain of Responsibilityパターンではないと思います。しかし、実際のシステムでは、責任の純粋なチェーンを見つけるのは困難です。あなたは責任のチェーン責任パターンのでしょうではない不純なチェーンに付着した場合、その後、Chain of Responsibilityパターンはあまり意味がありません。
フィルタ（フィルタ責任パターンの典型的鎖）
chain.doFilter（REQ、RES）によるコールフィルタ方法
FilterChainImplソース
public void doFilter(ServletRequest paramServletRequest, ServletResponse paramServletResponse)
throws IOException, ServletException
{
Filter localFilter = (Filter)this.filters.get(this.index++);
localFilter.doFilter(paramServletRequest, paramServletResponse, this);
}プロパティチェーンオブジェクトLINKLISTこのサイクルを終了します。
条件ときフィルタ次には満たされていない場合の処理（バックパスを含む処理）。（これは責任のパターンの個人的な感情の不純なチェーンと、次のパスの両方の契約ですが、彼は自分の責任の範囲内で取り扱いしています）。
利点：1、デカップル。これは、送信側と受信側のデカップリングを要求します。図2に示すように、オブジェクトが簡略化されます。このようなオブジェクトは鎖の構造を知る必要がないこと。図3に示すように、オブジェクトに責任を割り当てる柔軟性を高めます。チェーンのメンバーまたはその順序の動員を変更することにより、動的に責任を追加または削除することができます。4、簡単に新しいクラスリクエスト処理を追加します。
短所：1、必ずしも要求が受信される保証はありません。デバッグコードを実行すると、サイクル呼び出しを引き起こす可能性がある場合は、図2に示すように、システムのパフォーマンスが影響を受けたが、非常に便利ではないであろう。図3は、容易に観察可能な特性ランタイム妨げるデバッグではないかもしれません。
フライ級
フライ利点は、大幅にメモリ内のオブジェクトの数を減少させることです。しかし、それは支払った価格が非常に高いことを行うことです：
●フライ級は、システムがより複雑になります。オブジェクトを共有するためには、複雑なロジックを作るいくつかの状況の外である必要があります。
●フライ級フライ級オブジェクトの外部の状態、外部の読み出し動作時間が若干長くなる状態ようになっています。
実際には、一般的ではないデザインパターンは、それは主に、基礎となる設計で使用されている工場、シングルトン、戦略、装飾、および他の観察モードよりもフライパターン、以上、前述したような文字列クラスのvalueOfの整数（ int）メソッド。
概要：類似点と相違点は、シングルトンパターンmetapatternsを楽しみます
フライのみ要件を満たすために被験者が必要複数のオブジェクトを配置するために使用されるオブジェクト・レベル、およびクラスレベルが単一の実施形態であり、そのクラスはAをインスタンス化することができますオブジェクトは、いわば、特定のコードに保持されていない単一の実施形態フライ級のデザインパターンの特殊なケースであり、コードは、さまざまな方法のn個で実現されてもよい、との単一の実施形態フライ級実装として見ることができます彼は、より厳密に制御対象のフライ級の一意性よりもです。
ステータス意味：
フライ級固有状態オブジェクトが環境の変化に伴って変化しないが、状態情報は、フライ級の点で任意のターゲットに対して、オブジェクト内の共有要素に格納され、従って、固有状態を共有することができます、その値は同じです。「黒点」と「ホワイトアウト」の上に募集、それが本来の状態である状態を表しています。
ユン外側のステータス：
フライ級クラスの状態が第2の物体の外部潤状態であり、それは環境が変化するにつれて変化するので、状態は共有されていない、別の共有要素オブジェクトのために、その値が異なっていてもよいですA。フライ級は、フライ級のオブジェクトが作成された後、クライアントによって保存されなければならない状態の外ユンオブジェクト、あなたは時間を必要として、バックギャモンなどの内部フライ級オブジェクト位置情報に渡され、フライ級オブジェクトはユン外に表されます状態。
したがって、外側のフライ級ユン固有状態のオブジェクトが互いに関連付けられていない、それぞれ他の二つの状態は無関係です。
また、フライ級=シングルトンファクトリパターン+ +合成モードと言われた
パーソナル理解（固有状態は単純な関心である、プラス状態外部ユンは、工場出荷時のパターンは、シングルトンを作成するために使用され、合成パターンを使用することですの）
