構造モデルのデザインパターン（C）

構造モデルは、より大きな構造の中に、クラスやオブジェクトの特定のレイアウトを押してくださいする方法について説明します。これは、ポリマー組成物または複合オブジェクトの使用を排除するクラスとインタフェースを整理する継承メカニズムを使用して、オブジェクトおよびクラス構造モデル構造モデルに前者に分割されます。

下部連結関係より組み合わせまたは集約関係継承関係に起因する「合成多重原理」を満たすために、構造モデルは、クラス構造スキーマよりも大きな柔軟性を有する物体。

構造モデルは、7種類に分けられます。

• プロキシ（代理）モード：オブジェクトへのアクセスを制御するための薬剤を提供すること。すなわち、間接的にプロキシクライアントを経由して、オブジェクトにアクセスすることにより、制限、オブジェクトの一部の機能を強化または変更します。
• アダプタ（アダプタ）モード：クライアントは、互換性のないインターフェースに起因するもののような他のインターフェースが、そうでなければ作業と一緒に働くことができない基づいて期待クラスインターフェースを変換。
• 橋（ブリッジ）モード：抽象化と分離、それらは独立して変えることができるようになっています。その代わりに、継承の組み合わせの関係によって達成され、抽象化は、カップリングの二つの可変程度の大きさを低減するために実装されています。
• デコレーション（デコ）モード：動的に余分な機能を高めるために、あるオブジェクトにいくつかの責任を追加します。
• 外観（ファサード）モード：複数の複雑なサブシステムに一貫性のあるインターフェースを提供し、これらのサブシステムは、より簡単にアクセスできます。
• フライ級（フライ級）モード：使用の共有が有効利用にきめ細かいオブジェクトの多くをサポートします。
• （コンポジット）モードの組合せは、ユーザがオブジェクトと個々のオブジェクトの同一の組み合わせへのアクセスを有するように、階層ツリーにオブジェクト。

加えて、7より構造モデル、アダプタモード 2つのカテゴリに分類され、構造モデルと構造物の二つのモード、他のすべての構造モデルに属するオブジェクト、次は私たちは、それぞれに詳細にその特性、構造およびアプリケーションを紹介します。

 

1、プロキシモード

オブジェクトプロキシへの制御アクセスを提供することを目的とする与える1）何らかの理由のために必要。この場合、オブジェクトは、適合しない、またはアクセスとターゲットオブジェクトとの間の仲介者として、ターゲット・オブジェクトへのプロキシオブジェクトを直接参照にアクセスすることはできません。

プロキシモードの主な利点は以下のとおりです。

• 仲介役を果たし、クライアントと対象物とターゲットオブジェクトの役割を保護するためにプロキシモード。
• プロキシオブジェクトは、ターゲットオブジェクトの機能を拡張することができます。
• 対象物を分離することができるクライアント・プロキシ・モード、結合度をある程度低減されます。

主な欠点は以下のとおりです。

• クライアントと対象物との間で、増加するプロキシオブジェクトである遅い要求処理が発生します。
• これは、システムの複雑さを増加させます。

 

2）アーキテクチャと実装

代理店モデルの主な役割は次の通り。

1. 抽象トピック（主題）カテゴリ：実際のビジネスの方法やテーマインタフェースまたは抽象クラス宣言によって達成プロキシオブジェクト。
2. レアルテーマ（実物）カテゴリ：抽象特定のビジネストピックを達成、実際のオブジェクトは、プロキシオブジェクトによって表され、オブジェクトは究極の基準となります。
3. プロキシ（代理）クラス：実際のテーマと同じインタフェースを提供し、内部が実際の被写体への参照が含まれ、それは、アクセス制御、または実際のテーマの機能を拡張することができます。

 

 

 

// 抽象的なテーマ
インターフェース件名
{ 
    無効要求（）; 
} 
// 実際のテーマ
クラスは RealSubject 実装の件名
{ 
    公共 空のリクエスト（）
    { 
        System.out.printlnは（「アクセス本当のテーマ別のアプローチを...」）; 
    } 
} 
// プロキシ
クラスのプロキシが実装件名
{ 
    プライベートRealSubject RealSubject;
     公共 無効要求（）
    { 
        IF（RealSubject == nullの）
        {
            RealSubject= 新新RealSubject（）; 
        } 
        preRequest（）; 
        realSubject.Request（）; 
        postRequest（）; 
    } 
    パブリック 無効preRequest（）
    { 
        System.out.printlnは（ "前処理前のアクセスに対する真のテーマ。" ）; 
    } 
    公共 のボイドpostRequest （）
    { 
        System.out.printlnは（ "本当のテーマにアクセスした後、後続のプロセス。" ）; 
    } 
}

パブリック クラスProxyTest 
{ 
    公共 静的 ボイドメイン（文字列[]引数）
    { 
        プロキシプロキシ = 新しいプロキシ（）。
        proxy.Request（）; 
    } 
}

結果：

前のアクセス本当のテーマに前処理。
アクセス方法...本当のテーマ
訪問の本当のテーマの後に後続の処理。

 

 

3）アプリケーションシナリオ

• リモートエージェントは、このアプローチは、ターゲットオブジェクトがクライアントのアクセスを容易にするため、異なるアドレス空間に存在するという事実を隠すために通常です。ユーザーのファイルシステムの仮想ハードディスクを作成するときに、ユーザーがいくつかのネットワークディスクスペースを適用し、例えば、ユーザーが実際にネットワークのディスクスペースにアクセスされた仮想ハー​​ドディスクにアクセスします。
• あなたが聴衆多くのオーバーヘッドを作成したいときにアラート、このアプローチは、一般的に使用されています。例えば、大きな画像をダウンロードして、あなたは、実際のオブジェクトに小さな割合を置き換えるユーザーに遅いサーバー感を解消するために、仮想エージェントを開始することができ、より複雑な計算に時間のいくつかの短い期間のために長い時間がかかり、完了することはできません。
• Securityエージェント、通常、顧客のさまざまな種類を制御するために使用されるこのアプローチは、実際のオブジェクトにアクセスします。
• ターゲットオブジェクトを呼び出すときに、インテリジェント指導が主に使用され、プロキシは、いくつかの追加処理機能を付けます。実際のオブジェクトを計算する、たとえばオブジェクトが参照されていない場合、それは自動的に解除することができるように、基準関数の数を増加させました。
• 怠惰な負荷は、システムのパフォーマンス、目標の遅延ローディングを改善するために参照してください。例えば、Hibernateの  存在及び特性関連する遅延ローディング遅延ローディングテーブル上。

 

4）拡張

プロキシモードは、先に説明して、プロキシクラスは、実際のトピックへの参照が含まれている、このアプローチには2つの欠点があります。

1. エージェントをテーマにした対応の本当の主題、テーマは本物の薬を高めるために増加しなければなりません。
2. デザインエージェンシー本当のテーマは、すでに存在している必要があります前に、柔軟性に劣ります。動的プロキシモードのような、上記の問題を解決することができる  春 AOP、図に示した構造4

 

 

 

図2に示すように、アダプタモード（アダプタ）

1）変換クラス・インターフェース・クライアントは、このような作業と一緒に動作する、さもなければできない基づいて互換性のないインターフェースによるもののような別のインタフェースを、期待します。アダプタモードが後者よりも前者の間の結合、モードベースの構造および構造物に2つのモードが分割されて、プログラマが必要とされる従来のコンポーネントライブラリ関連するコンポーネントの内部構造は、比較的あまり使用されませんもっと。

 次のようにこのモードの主な利点はあります。

• クライアントは透過的にインタフェースアダプタを介してターゲットを呼び出すことができます。
• 既存のクラスと多重化は、プログラマの必要性は、フィッタ、元のコードの再利用既存のクラスを変更できません。
• ターゲットクラスとフィッタターゲットクラスとクラスのインタフェースアダプタの問題を解決するデカップリングのクラスが矛盾しています。

その欠点は以下のとおりです。クラスのアダプタは、アダプタは、より複雑なプロセスの実現を交換してください。

 

2）アーキテクチャと実装

アダプタモード（アダプタ）は、次の主要な役割が含まれています。

• 標的（ターゲット）インターフェース：抽象クラスまたはインタフェースとすることができるビジネス予想インタフェースの現在のシステム。
• フィッター（Adaptee）クラス：それはアクセスされ、インタフェースコンポーネントが既存のコンポーネントライブラリを適合しました。
• アダプタ（アダプタ）クラス：それは、ターゲット・インターフェースに継承または参照オブジェクトフィッタおよびフィッタ変換インタフェースにより、コンバータである顧客は、アダプタの形式へのアクセスを許可する宛先インターフェイスに係ります。

クラスアダプタモード：

 

 

package adapter;
//目标接口
interface Target
{
    public void request();
}
//适配者接口
class Adaptee
{
    public void specificRequest()
    {       
        System.out.println("适配者中的业务代码被调用！");
    }
}
//类适配器类
class ClassAdapter extends Adaptee implements Target
{
    public void request()
    {
        specificRequest();
    }
}
//客户端代码
public class ClassAdapterTest
{
    public static void main(String[] args)
    {
        System.out.println("类适配器模式测试：");
        Target target = new ClassAdapter();
        target.request();
    }
}

运行结果：

类适配器模式测试：
适配者中的业务代码被调用！

 

对象适配器模式：

 

 

 

 

 

 

package adapter;
//对象适配器类
class ObjectAdapter implements Target
{
    private Adaptee adaptee;
    public ObjectAdapter(Adaptee adaptee)
    {
        this.adaptee=adaptee;
    }
    public void request()
    {
        adaptee.specificRequest();
    }
}
//客户端代码
public class ObjectAdapterTest
{
    public static void main(String[] args)
    {
        System.out.println("对象适配器模式测试：");
        Adaptee adaptee = new Adaptee();
        Target target = new ObjectAdapter(adaptee);
        target.request();
    }
}

运行结果：

对象适配器模式测试：
适配者中的业务代码被调用！

说明：对象适配器模式中的“目标接口”和“适配者类”的代码同类适配器模式一样，只要修改适配器类和客户端的代码即可。

 

3）应用场景

适配器模式（Adapter）通常适用于以下场景。

• 以前开发的系统存在满足新系统功能需求的类，但其接口同新系统的接口不一致。
• 使用第三方提供的组件，但组件接口定义和自己要求的接口定义不同。

4）扩展

适配器模式（Adapter）可扩展为双向适配器模式，双向适配器类既可以把适配者接口转换成目标接口，也可以把目标接口转换成适配者接口

 

 

 

3、桥接（Bridge）模式

1）将抽象与实现分离，使它们可以独立变化。它是用组合关系代替继承关系来实现，从而降低了抽象和实现这两个可变维度的耦合度。

 桥接（Bridge）模式的优点是：

• 由于抽象与实现分离，所以扩展能力强；
• 其实现细节对客户透明。

缺点是：由于聚合关系建立在抽象层，要求开发者针对抽象化进行设计与编程，这增加了系统的理解与设计难度。

 

2）结构与实现

 桥接（Bridge）模式包含以下主要角色。

• 抽象化（Abstraction）角色：定义抽象类，并包含一个对实现化对象的引用。
• 扩展抽象化（Refined    Abstraction）角色：是抽象化角色的子类，实现父类中的业务方法，并通过组合关系调用实现化角色中的业务方法。
• 实现化（Implementor）角色：定义实现化角色的接口，供扩展抽象化角色调用。
• 具体实现化（Concrete Implementor）角色：给出实现化角色接口的具体实现。

 

 

public class BridgeTest
{
    public static void main(String[] args)
    {
        Implementor imple=new ConcreteImplementorA();
        Abstraction abs=new RefinedAbstraction(imple);
        abs.Operation();
    }
}
//实现化角色
interface Implementor
{
    public void OperationImpl();
}
//具体实现化角色
class ConcreteImplementorA implements Implementor
{
    public void OperationImpl()
    {
        System.out.println("具体实现化(Concrete Implementor)角色被访问" );
    }
}
//抽象化角色
abstract class Abstraction
{
   protected Implementor imple;
   protected Abstraction(Implementor imple)
   {
       this.imple=imple;
   }
   public abstract void Operation();   
}
//扩展抽象化角色
class RefinedAbstraction extends Abstraction
{
   protected RefinedAbstraction(Implementor imple)
   {
       super(imple);
   }
   public void Operation()
   {
       System.out.println("扩展抽象化(Refined Abstraction)角色被访问" );
       imple.OperationImpl();
   }
}

View Code

运行结果

扩展抽象化(Refined Abstraction)角色被访问
具体实现化(Concrete Implementor)角色被访问

 

3）应用场景

 桥接模式通常适用于以下场景。

1. 当一个类存在两个独立变化的维度，且这两个维度都需要进行扩展时。
2. 当一个系统不希望使用继承或因为多层次继承导致系统类的个数急剧增加时。
3. 当一个系统需要在构件的抽象化角色和具体化角色之间增加更多的灵活性时。

 

4）扩展

在软件开发中，有时桥接（Bridge）模式可与适配器模式联合使用。当桥接（Bridge）模式的实现化角色的接口与现有类的接口不一致时，可以在二者中间定义一个适配器将二者连接起来

 

 

 

4、装饰（Decorator）模式

1）指在不改变现有对象结构的情况下，动态地给该对象增加一些职责（即增加其额外功能）的模式，它属于对象结构型模式。

装饰（Decorator）模式的主要优点有：

• 采用装饰模式扩展对象的功能比采用继承方式更加灵活。
• 可以设计出多个不同的具体装饰类，创造出多个不同行为的组合。

其主要缺点是：装饰模式增加了许多子类，如果过度使用会使程序变得很复杂。

 

2）结构与实现

 通常情况下，扩展一个类的功能会使用继承方式来实现。但继承具有静态特征，耦合度高，并且随着扩展功能的增多，子类会很膨胀。如果使用组合关系来创建一个包装对象（即装饰对象）来包裹真实对象，并在保持真实对象的类结构不变的前提下，为其提供额外的功能，这就是装饰模式的目标。

装饰模式主要包含以下角色。

• 抽象构件（Component）角色：定义一个抽象接口以规范准备接收附加责任的对象。
• 具体构件（Concrete    Component）角色：实现抽象构件，通过装饰角色为其添加一些职责。
• 抽象装饰（Decorator）角色：继承抽象构件，并包含具体构件的实例，可以通过其子类扩展具体构件的功能。
• 具体装饰（ConcreteDecorator）角色：实现抽象装饰的相关方法，并给具体构件对象添加附加的责任。

public class DecoratorPattern
{
    public static void main(String[] args)
    {
        Component p=new ConcreteComponent();
        p.operation();
        System.out.println("---------------------------------");
        Component d=new ConcreteDecorator(p);
        d.operation();
    }
}
//抽象构件角色
interface  Component
{
    public void operation();
}
//具体构件角色
class ConcreteComponent implements Component
{
    public ConcreteComponent()
    {
        System.out.println("创建具体构件角色");       
    }   
    public void operation()
    {
        System.out.println("调用具体构件角色的方法operation()");           
    }
}
//抽象装饰角色
class Decorator implements Component
{
    private Component component;   
    public Decorator(Component component)
    {
        this.component=component;
    }   
    public void operation()
    {
        component.operation();
    }
}
//具体装饰角色
class ConcreteDecorator extends Decorator
{
    public ConcreteDecorator(Component component)
    {
        super(component);
    }   
    public void operation()
    {
        super.operation();
        addedFunction();
    }
    public void addedFunction()
    {
        System.out.println("为具体构件角色增加额外的功能addedFunction()");           
    }
}

运行结果

创建具体构件角色
调用具体构件角色的方法operation()
---------------------------------
调用具体构件角色的方法operation()
为具体构件角色增加额外的功能addedFunction()

 

3）应用场景

 前面讲解了关于装饰模式的结构与特点，下面介绍其适用的应用场景，装饰模式通常在以下几种情况使用。

• 当需要给一个现有类添加附加职责，而又不能采用生成子类的方法进行扩充时。例如，该类被隐藏或者该类是终极类或者采用继承方式会产生大量的子类。
• 当需要通过对现有的一组基本功能进行排列组合而产生非常多的功能时，采用继承关系很难实现，而采用装饰模式却很好实现。
• 当对象的功能要求可以动态地添加，也可以再动态地撤销时。

装饰模式在 Java 语言中的最著名的应用莫过于 Java I/O 标准库的设计了。例如，InputStream 的子类 FilterInputStream，OutputStream 的子类 FilterOutputStream，Reader 的子类 BufferedReader 以及 FilterReader，还有 Writer 的子类 BufferedWriter、FilterWriter 以及 PrintWriter 等，它们都是抽象装饰类。

下面代码是为 FileReader 增加缓冲区而采用的装饰类 BufferedReader 的例子：

BufferedReader in=new BufferedReader(new FileReader("filename.txtn));
String s=in.readLine();

 

4）扩展

装饰模式所包含的 4 个角色不是任何时候都要存在的，在有些应用环境下模式是可以简化的，如以下两种情况。

(1) 如果只有一个具体构件而没有抽象构件时，可以让抽象装饰继承具体构件

 

 

(2) 如果只有一个具体装饰时，可以将抽象装饰和具体装饰合并

 

 

 

 

5、外观（Facade）模式

1）是一种通过为多个复杂的子系统提供一个一致的接口，而使这些子系统更加容易被访问的模式。该模式对外有一个统一接口，外部应用程序不用关心内部子系统的具体的细节，这样会大大降低应用程序的复杂度，提高了程序的可维护性。

 外观（Facade）模式是“迪米特法则”的典型应用，它有以下主要优点。

1. 降低了子系统与客户端之间的耦合度，使得子系统的变化不会影响调用它的客户类。
2. 对客户屏蔽了子系统组件，减少了客户处理的对象数目，并使得子系统使用起来更加容易。
3. 降低了大型软件系统中的编译依赖性，简化了系统在不同平台之间的移植过程，因为编译一个子系统不会影响其他的子系统，也不会影响外观对象。

外观（Facade）模式的主要缺点如下。

1. 不能很好地限制客户使用子系统类。
2. 增加新的子系统可能需要修改外观类或客户端的源代码，违背了“开闭原则”。

 

2）结构与实现

 外观（Facade）模式的结构比较简单，主要是定义了一个高层接口。它包含了对各个子系统的引用，客户端可以通过它访问各个子系统的功能。现在来分析其基本结构和实现方法。

外观（Facade）模式包含以下主要角色。

• 外观（Facade）角色：为多个子系统对外提供一个共同的接口。
• 子系统（Sub System）角色：实现系统的部分功能，客户可以通过外观角色访问它。
• 客户（Client）角色：通过一个外观角色访问各个子系统的功能。

 

 

public class FacadePattern
{
    public static void main(String[] args)
    {
        Facade f=new Facade();
        f.method();
    }
}
//外观角色
class Facade
{
    private SubSystem01 obj1=new SubSystem01();
    private SubSystem02 obj2=new SubSystem02();
    private SubSystem03 obj3=new SubSystem03();
    public void method()
    {
        obj1.method1();
        obj2.method2();
        obj3.method3();
    }
}
//子系统角色
class SubSystem01
{
    public  void method1()
    {
        System.out.println("子系统01的method1()被调用！");
    }   
}
//子系统角色
class SubSystem02
{
    public  void method2()
    {
        System.out.println("子系统02的method2()被调用！");
    }   
}
//子系统角色
class SubSystem03
{
    public  void method3()
    {
        System.out.println("子系统03的method3()被调用！");
    }   
}

View Code

运行结果

子系统01的method1()被调用！
子系统02的method2()被调用！
子系统03的method3()被调用！

 

3）应用场景

 通常在以下情况下可以考虑使用外观模式。

1. 对分层结构系统构建时，使用外观模式定义子系统中每层的入口点可以简化子系统之间的依赖关系。
2. 当一个复杂系统的子系统很多时，外观模式可以为系统设计一个简单的接口供外界访问。
3. 当客户端与多个子系统之间存在很大的联系时，引入外观模式可将它们分离，从而提高子系统的独立性和可移植性。

4）扩展

在外观模式中，当增加或移除子系统时需要修改外观类，这违背了“开闭原则”。如果引入抽象外观类，则在一定程度上解决了该问题

 

 

 

6、享元（Flyweight）模式

1）运用共享技术来有効地支持大量细粒度对象的复用。它通过共享已经存在的又橡来大幅度减少需要创建的对象数量、避免大量相似类的开销，从而提高系统资源的利用率。

 享元模式的主要优点是：相同对象只要保存一份，这降低了系统中对象的数量，从而降低了系统中细粒度对象给内存带来的压力。

其主要缺点是：

1. 为了使对象可以共享，需要将一些不能共享的状态外部化，这将增加程序的复杂性。
2. 读取享元模式的外部状态会使得运行时间稍微变长。

 

2）结构与实现

 享元模式中存在以下两种状态：

1. 内部状态，即不会随着环境的改变而改变的可共享部分；
2. 外部状态，指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态，并将外部状态外部化。下面来分析其基本结构和实现方法。

享元模式的主要角色有如下。

• 抽象享元角色（Flyweight）:是所有的具体享元类的基类，为具体享元规范需要实现的公共接口，非享元的外部状态以参数的形式通过方法传入。
• 具体享元（Concrete Flyweight）角色：实现抽象享元角色中所规定的接口。
• 非享元（Unsharable Flyweight)角色：是不可以共享的外部状态，它以参数的形式注入具体享元的相关方法中。
• 享元工厂（Flyweight Factory）角色：负责创建和管理享元角色。当客户对象请求一个享元对象时，享元工厂检査系统中是否存在符合要求的享元对象，如果存在则提供给客户；如果不存在的话，则创建一个新的享元对象。

 

 图中的 UnsharedConcreteFlyweight 是与享元角色，里面包含了非共享的外部状态信息 info；而 Flyweight 是抽象享元角色，里面包含了享元方法 operation(UnsharedConcreteFlyweight state)，非享元的外部状态以参数的形式通过该方法传入；ConcreteFlyweight 是具体享元角色，包含了关键字 key，它实现了抽象享元接口；FlyweightFactory 是享元工厂角色，它逝关键字 key 来管理具体享元；客户角色通过享元工厂获取具体享元，并访问具体享元的相关方法。

import java.util.HashMap;
public class FlyweightPattern
{
    public static void main(String[] args)
    {
        FlyweightFactory factory=new FlyweightFactory();
        Flyweight f01=factory.getFlyweight("a");
        Flyweight f02=factory.getFlyweight("a");
        Flyweight f03=factory.getFlyweight("a");
        Flyweight f11=factory.getFlyweight("b");
        Flyweight f12=factory.getFlyweight("b");       
        f01.operation(new UnsharedConcreteFlyweight("第1次调用a。"));       
        f02.operation(new UnsharedConcreteFlyweight("第2次调用a。"));       
        f03.operation(new UnsharedConcreteFlyweight("第3次调用a。"));       
        f11.operation(new UnsharedConcreteFlyweight("第1次调用b。"));       
        f12.operation(new UnsharedConcreteFlyweight("第2次调用b。"));
    }
}
//非享元角色
class UnsharedConcreteFlyweight
{
    private String info;
    UnsharedConcreteFlyweight(String info)
    {
        this.info=info;
    }
    public String getInfo()
    {
        return info;
    }
    public void setInfo(String info)
    {
        this.info=info;
    }
}
//抽象享元角色
interface Flyweight
{
    public void operation(UnsharedConcreteFlyweight state);
}
//具体享元角色
class ConcreteFlyweight implements Flyweight
{
    private String key;
    ConcreteFlyweight(String key)
    {
        this.key=key;
        System.out.println("具体享元"+key+"被创建！");
    }
    public void operation(UnsharedConcreteFlyweight outState)
    {
        System.out.print("具体享元"+key+"被调用，");
        System.out.println("非享元信息是:"+outState.getInfo());
    }
}
//享元工厂角色
class FlyweightFactory
{
    private HashMap<String, Flyweight> flyweights=new HashMap<String, Flyweight>();
    public Flyweight getFlyweight(String key)
    {
        Flyweight flyweight=(Flyweight)flyweights.get(key);
        if(flyweight!=null)
        {
            System.out.println("具体享元"+key+"已经存在，被成功获取！");
        }
        else
        {
            flyweight=new ConcreteFlyweight(key);
            flyweights.put(key, flyweight);
        }
        return flyweight;
    }
}

运行结果

具体享元a被创建！
具体享元a已经存在，被成功获取！
具体享元a已经存在，被成功获取！
具体享元b被创建！
具体享元b已经存在，被成功获取！
具体享元a被调用，非享元信息是:第1次调用a。
具体享元a被调用，非享元信息是:第2次调用a。
具体享元a被调用，非享元信息是:第3次调用a。
具体享元b被调用，非享元信息是:第1次调用b。
具体享元b被调用，非享元信息是:第2次调用b。

 

3）应用场景

 享元模式是通过减少内存中对象的数量来节省内存空间的，所以以下几种情形适合采用享元模式。

1. 系统中存在大量相同或相似的对象，这些对象耗费大量的内存资源。
2. 大部分的对象可以按照内部状态进行分组，且可将不同部分外部化，这样每一个组只需保存一个内部状态。
3. 由于享元模式需要额外维护一个保存享元的数据结构，所以应当在有足够多的享元实例时才值得使用享元模式。

 

4）扩展

在前面介绍的享元模式中，其结构图通常包含可以共享的部分和不可以共享的部分。在实际使用过程中，有时候会稍加改变，即存在两种特殊的享元模式：单纯享元模式和复合享元模式，

(1) 单纯享元模式，这种享元模式中的所有的具体享元类都是可以共享的，不存在非共享的具体享元类

 

 

(2) 复合享元模式，这种享元模式中的有些享元对象是由一些单纯享元对象组合而成的，它们就是复合享元对象。虽然复合享元对象本身不能共享，但它们可以分解成单纯享元对象再被共享

 

 

 

 

原文链接：http://c.biancheng.net/design_pattern/