オブジェクトのパフォーマンスモード：オブジェクト指向の抽象化で問題に良い解決策が、価格を支払わなければならないことが避けられなければなりません。一般的な用語については、オブジェクト指向の方法で最もコストは無視できるが、いくつかのケースでは、オブジェクトは、コストがために注意して取り扱わなければならないもたらすことです。

典型的なモード：シングルトンパターン（シングルトン）、共有モード（フライ）。

シングルピースモード

1.動機

ソフトウェアシステムでは、多くの場合、このような特別なクラスを持って、彼らは唯一つのインスタンスは、その論理的正しさ、そして優れた効率性を確保するために、システム内に存在していることを確認する必要があります。

2.役割

従来の構造を迂回クラス（設計者の責任）のインスタンスを1つだけ確実にするメカニズムを提供します。

3.定義

クラスのインスタンスを1つだけ確認しており、この例のグローバルなポイントを提供。

4.コード

// 单件模式实现
クラスシングルトン{
 プライベート：
    シングルトン（）; 
    シングルトン（CONSTシングルトン＆他）;
パブリック：
     静的シングルトン* のgetInstance（）;
    静的シングルトン* m_instance。
}。
シングルトン *シングルトン:: m_instance = nullptr;
// 线程非安全版本 
シングルトン* シングルトン::のgetInstance（）{
     場合（m_instance == nullptr）{ 
        m_instance = 新しいシングルトン（）; 
    } 
    戻りm_instance。
}
// スレッドセーフなバージョンが、価格が高すぎるロックです 
シングルトン* シングルトン::のgetInstance（）{ 
    ロックロック;
     IF（m_instance == nullptr）{ 
        m_instance = 新しい新しいシングルトン（）; 
    } 
    戻りm_instance; 
} 
// ダブルチェックロック、しかし、（詳細本明細書リオーダーの場合で説明していない）危険リオーダ読み書きメモリに起因 
シングルトン* シングルトン::のgetInstance（）{
     IF（m_instance == nullptr A）{ 
        ロックロック;
         IF（m_instance == nullptr A）{ 
            m_instance = 新しい新しいシングルトン（） ; 
        } 
    }
    リターンm_instance。
}

5.解析

いくつかのクラスでは、インスタンスは1つだけ非常に重要です。例えば：システムがあってもよいが、それだけ多くの一つによってプリンタをスプール印刷するべきであるが、唯一のファイルシステムとウィンドウマネージャが存在すべきである。デジタルフィルタのみ1つのA / D変換器を有することができ、唯一の会計システムこれは、1つの会社に専念することができます。これは、デザイナーのカテゴリの責任ではなく、使用者の責任である必要があります。

上記のコードでは、シングルスレッドプログラムの非スレッドセーフなバージョンは安全であるが、マルチスレッドのために安全ではない。のみのために（スレッドセーフなバージョンの、マルチスレッドセーフを「ロック」を追加することにより、コストが高すぎるロックであります）ケースを読んで、ダブルチェックのためにロックを、「ロック」の前に、効率の向上とコストの削減にもチェックします。

6.構造

シングルトン：

インスタンスがクラスの動作であり、顧客が独自のインスタンスにアクセスできるようにするには、インスタンスの動作を定義します。

2.独自のインスタンスを作成するための責任を負う可能。

7.まとめ

例1.Singletonモード構成は、保護サブクラスを許可するように設定されてもよいです。

これは、オブジェクトインスタンス、シングルトンパターンの本来の意図に反して複数の生じ得るよう2.Singletonモードは、一般に、コピーコンストラクタとクローンインターフェースをサポートしていません。

ダブルチェックロックの適切な実施にシングルトン、注意を払うのセキュアなマルチスレッド環境を実現するために3。

第二に、共有モード

1.動機

ランニング時にコスト高につながる、すぐにシステムのきめ細かいオブジェクトで満たされるソフトウェアシステムの大規模な数の純粋な目標計画を発行します - 主にメモリ需要側のコストを指します。

2.役割

外部クライアントがまだ透過的に動作させるために、オブジェクト指向の方法を使用することができますのでこと、同時に、きめ細かいオブジェクトの問題の多くを避けてください。

3.定義

きめ細かい多数のオブジェクトをサポートするために、共有を使用します。

4.コード

// 运用共享模式
クラスフォント{
 プライベート：
     文字列のキー。
公共：
    フォント（のconst  文字列＆キー）{
         // ... 
    } 
}; 
クラスFontFactory {
 プライベート：
    マップ < 文字列、フォント*> fontPool。
公共：
    フォント * GETFONT（CONST  文字列＆キー）{ 
        マップ < 文字列、フォント*> ::イテレータアイテム= fontPool.find（キー）。
        もしアイテム（！=footPool.end（））{
             リターンfontPool [キー]。
        } 
        他{ 
            フォント *フォント= 新しいフォント（キー）。
            fontPool [キー] = フォント。
            戻り値のフォント。
        } 
    } 
    ボイドクリア（）{ 
    } 
}。

5.解析

オブジェクトの数がモデリングによって表されるためであると一般的には大きすぎるそれらの実体や概念をフライ級。たとえば、各文字フライ級、フライ級各店舗文字コードのドキュメントエディタを作成することができます。直接のリターンはConcreteFlyweightは（FlyweightFactoryオブジェクトを通してオブジェクトを取得することがあれば、あなたがフライ級オブジェクトを呼び出す必要があるたびに、ユーザーの必要性は直接、インスタンス化しますが、最初に作成する前にオブジェクトが存在するかどうかを判断できない、ない場合は、オブジェクトが作成され、プールオブジェクトに、戻る。）、従ってそれらの適切な共有を確保します。

6.構造

7.まとめ

1.オブジェクト指向の抽象化は、問題を解決しますが、マシン上でプログラムを実行するエンティティとして、我々は、価格の問題にオブジェクトを検討する必要があります。コストの問題を解決するために、主にメインオブジェクト指向をFlyweigh、抽象的な問題には触れないでください。

2.Flyweighオブジェクト共有それによってきめ細かいオブジェクトを低減する、システム内のオブジェクトの数を減らすことへのアプローチは、システムメモリの圧力をもたらします。特定の実装では、我々は、オブジェクトの処理状態に注意を払う必要があります。

3.オブジェクトオーバーヘッドメモリを増加させるオブジェクトの膨大な数、 - 数がアプリケーションを評価する必要性の大きさに応じ。

学習記録：「C ++のデザインパターン - スピーカーJianzhong」5「オブジェクトのプロパティ」モード

シングルピースモード

1.動機

2.役割

3.定義

4.コード

5.解析

6.構造

7.まとめ

第二に、共有モード

1.動機

2.役割

3.定義

4.コード

5.解析

6.構造

7.まとめ

おすすめ