• 享元模式

    5. 享元模式 — Graphic Design Patterns https://design-patterns.readthedocs.io/zh_CN/latest/structural_patterns/flyweight.html

    5. 享元模式

    5.1. 模式动机

    面向对象技术可以很好地解决一些灵活性或可扩展性问题，但在很多情况下需要在系统中增加类和对象的个数。当对象数量太多时，将导致运行代价过高，带来性能下降等问题。

    • 享元模式正是为解决这一类问题而诞生的。享元模式通过共享技术实现相同或相似对象的重用。
    • 在享元模式中可以共享的相同内容称为内部状态(IntrinsicState)，而那些需要外部环境来设置的不能共享的内容称为外部状态(Extrinsic State)，由于区分了内部状态和外部状态，因此可以通过设置不同的外部状态使得相同的对象可以具有一些不同的特征，而相同的内部状态是可以共享的。
    • 在享元模式中通常会出现工厂模式，需要创建一个享元工厂来负责维护一个享元池(Flyweight Pool)用于存储具有相同内部状态的享元对象。
    • 在享元模式中共享的是享元对象的内部状态，外部状态需要通过环境来设置。在实际使用中，能够共享的内部状态是有限的，因此享元对象一般都设计为较小的对象，它所包含的内部状态较少，这种对象也称为细粒度对象。享元模式的目的就是使用共享技术来实现大量细粒度对象的复用。

    5.2. 模式定义

    享元模式(Flyweight Pattern)：运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用。由于享元模式要求能够共享的对象必须是细粒度对象，因此它又称为轻量级模式，它是一种对象结构型模式。

    5.3. 模式结构

    享元模式包含如下角色：

    • Flyweight: 抽象享元类
    • ConcreteFlyweight: 具体享元类
    • UnsharedConcreteFlyweight: 非共享具体享元类
    • FlyweightFactory: 享元工厂类

    5.4. 时序图

    5.5. 代码分析

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
    		 
    #include <iostream>
#include "ConcreteFlyweight.h"
#include "FlyweightFactory.h"
#include "Flyweight.h"
using namespace std;

int main(int argc, char *argv[])
{
	FlyweightFactory factory;
	Flyweight * fw = factory.getFlyweight("one");
	fw->operation();
	
	Flyweight * fw2 = factory.getFlyweight("two");
	fw2->operation();
	//aready exist in pool
	Flyweight * fw3 = factory.getFlyweight("one");
	fw3->operation();
	return 0;
}

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
    		 
    ///////////////////////////////////////////////////////////
//  FlyweightFactory.cpp
//  Implementation of the Class FlyweightFactory
//  Created on:      06-十月-2014 20:10:42
//  Original author: colin
///////////////////////////////////////////////////////////

#include "FlyweightFactory.h"
#include "ConcreteFlyweight.h"
#include <iostream>
using namespace std;

FlyweightFactory::FlyweightFactory(){

}



FlyweightFactory::~FlyweightFactory(){

}

Flyweight* FlyweightFactory::getFlyweight(string str){
	map<string,Flyweight*>::iterator itr = m_mpFlyweight.find(str);
	if(itr == m_mpFlyweight.end())
	{
		Flyweight * fw = new ConcreteFlyweight(str);
		m_mpFlyweight.insert(make_pair(str,fw));
		return fw;	
	}
	else
	{
		cout << "aready in the pool,use the exist one:" << endl;
		return itr->second;
	}		
}

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
    		 
    ///////////////////////////////////////////////////////////
//  ConcreteFlyweight.h
//  Implementation of the Class ConcreteFlyweight
//  Created on:      06-十月-2014 20:10:42
//  Original author: colin
///////////////////////////////////////////////////////////

#if !defined(EA_C0AF438E_96E4_46f1_ADEC_308EF16E11D1__INCLUDED_)
#define EA_C0AF438E_96E4_46f1_ADEC_308EF16E11D1__INCLUDED_

#include "Flyweight.h"
#include <string>
using namespace std;

class ConcreteFlyweight : public Flyweight
{

public:
	ConcreteFlyweight(string str);
	virtual ~ConcreteFlyweight();

	virtual void operation();

private:
	string intrinsicState;

};
#endif // !defined(EA_C0AF438E_96E4_46f1_ADEC_308EF16E11D1__INCLUDED_)

     1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
    		 
    ///////////////////////////////////////////////////////////
//  ConcreteFlyweight.cpp
//  Implementation of the Class ConcreteFlyweight
//  Created on:      06-十月-2014 20:10:42
//  Original author: colin
///////////////////////////////////////////////////////////

#include "ConcreteFlyweight.h"
#include <iostream>
using namespace std;


ConcreteFlyweight::ConcreteFlyweight(string str){
	intrinsicState = str;
}

ConcreteFlyweight::~ConcreteFlyweight(){

}

void ConcreteFlyweight::operation(){
	cout << "Flyweight[" << intrinsicState << "] do operation." << endl; 
}

    运行结果：

    ../_images/Flyweight_run.jpg

    5.6. 模式分析

    享元模式是一个考虑系统性能的设计模式，通过使用享元模式可以节约内存空间，提高系统的性能。

    享元模式的核心在于享元工厂类，享元工厂类的作用在于提供一个用于存储享元对象的享元池，用户需要对象时，首先从享元池中获取，如果享元池中不存在，则创建一个新的享元对象返回给用户，并在享元池中保存该新增对象。

    享元模式以共享的方式高效地支持大量的细粒度对象，享元对象能做到共享的关键是区分内部状态(Internal State)和外部状态(External State)。

    • 内部状态是存储在享元对象内部并且不会随环境改变而改变的状态，因此内部状态可以共享。
    • 外部状态是随环境改变而改变的、不可以共享的状态。享元对象的外部状态必须由客户端保存，并在享元对象被创建之后，在需要使用的时候再传入到享元对象内部。一个外部状态与另一个外部状态之间是相互独立的。

    5.8. 优点

    享元模式的优点

    • 享元模式的优点在于它可以极大减少内存中对象的数量，使得相同对象或相似对象在内存中只保存一份。
    • 享元模式的外部状态相对独立，而且不会影响其内部状态，从而使得享元对象可以在不同的环境中被共享。

    5.9. 缺点

    享元模式的缺点

    • 享元模式使得系统更加复杂，需要分离出内部状态和外部状态，这使得程序的逻辑复杂化。
    • 为了使对象可以共享，享元模式需要将享元对象的状态外部化，而读取外部状态使得运行时间变长。

    5.10. 适用环境

    在以下情况下可以使用享元模式：

    • 一个系统有大量相同或者相似的对象，由于这类对象的大量使用，造成内存的大量耗费。
    • 对象的大部分状态都可以外部化，可以将这些外部状态传入对象中。
    • 使用享元模式需要维护一个存储享元对象的享元池，而这需要耗费资源，因此，应当在多次重复使用享元对象时才值得使用享元模式。

    5.11. 模式应用

    享元模式在编辑器软件中大量使用，如在一个文档中多次出现相同的图片，则只需要创建一个图片对象，通过在应用程序中设置该图片出现的位置，可以实现该图片在不同地方多次重复显示。

    5.12. 模式扩展

    单纯享元模式和复合享元模式

    • 单纯享元模式：在单纯享元模式中，所有的享元对象都是可以共享的，即所有抽象享元类的子类都可共享，不存在非共享具体享元类。
    • 复合享元模式：将一些单纯享元使用组合模式加以组合，可以形成复合享元对象，这样的复合享元对象本身不能共享，但是它们可以分解成单纯享元对象，而后者则可以共享。

    享元模式与其他模式的联用

    • 在享元模式的享元工厂类中通常提供一个静态的工厂方法用于返回享元对象，使用简单工厂模式来生成享元对象。
    • 在一个系统中，通常只有唯一一个享元工厂，因此享元工厂类可以使用单例模式进行设计。
    • 享元模式可以结合组合模式形成复合享元模式，统一对享元对象设置外部状态。

    5.13. 总结

    • 享元模式运用共享技术有效地支持大量细粒度对象的复用。系统只使用少量的对象，而这些对象都很相似，状态变化很小，可以实现对象的多次复用，它是一种对象结构型模式。
    • 享元模式包含四个角色：抽象享元类声明一个接口，通过它可以接受并作用于外部状态；具体享元类实现了抽象享元接口，其实例称为享元对象；非共享具体享元是不能被共享的抽象享元类的子类；享元工厂类用于创建并管理享元对象，它针对抽象享元类编程，将各种类型的具体享元对象存储在一个享元池中。
    • 享元模式以共享的方式高效地支持大量的细粒度对象，享元对象能做到共享的关键是区分内部状态和外部状态。其中内部状态是存储在享元对象内部并且不会随环境改变而改变的状态，因此内部状态可以共享；外部状态是随环境改变而改变的、不可以共享的状态。
    • 享元模式主要优点在于它可以极大减少内存中对象的数量，使得相同对象或相似对象在内存中只保存一份；其缺点是使得系统更加复杂，并且需要将享元对象的状态外部化，而读取外部状态使得运行时间变长。
    • 享元模式适用情况包括：一个系统有大量相同或者相似的对象，由于这类对象的大量使用，造成内存的大量耗费；对象的大部分状态都可以外部化，可以将这些外部状态传入对象中；多次重复使用享元对象。

     享元设计模式 https://refactoringguru.cn/design-patterns/flyweight

    享元模式适合应用场景

     仅在程序必须支持大量对象且没有足够的内存容量时使用享元模式。

     应用该模式所获的收益大小取决于使用它的方式和情景。 它在下列情况中最有效：

    • 程序需要生成数量巨大的相似对象
    • 这将耗尽目标设备的所有内存
    • 对象中包含可抽取且能在多个对象间共享的重复状态。

     实现方式

    1. 将需要改写为享元的类成员变量拆分为两个部分：

      • 内在状态： 包含不变的、 可在许多对象中重复使用的数据的成员变量。
      • 外在状态： 包含每个对象各自不同的情景数据的成员变量

    2. 保留类中表示内在状态的成员变量， 并将其属性设置为不可修改。 这些变量仅可在构造函数中获得初始数值。

    3. 找到所有使用外在状态成员变量的方法， 为在方法中所用的每个成员变量新建一个参数， 并使用该参数代替成员变量。

    4. 你可以有选择地创建工厂类来管理享元缓存池， 它负责在新建享元时检查已有的享元。 如果选择使用工厂， 客户端就只能通过工厂来请求享元， 它们需要将享元的内在状态作为参数传递给工厂。

    5. 客户端必须存储和计算外在状态 （情景） 的数值， 因为只有这样才能调用享元对象的方法。 为了使用方便， 外在状态和引用享元的成员变量可以移动到单独的情景类中。

     享元模式优缺点

    •  如果程序中有很多相似对象， 那么你将可以节省大量内存。
    •  你可能需要牺牲执行速度来换取内存， 因为他人每次调用享元方法时都需要重新计算部分情景数据。
    •  代码会变得更加复杂。 团队中的新成员总是会问： ​ “为什么要像这样拆分一个实体的状态？”。

     与其他模式的关系

    • 你可以使用享元模式实现组合模式树的共享叶节点以节省内存。

    • 享元展示了如何生成大量的小型对象， 外观模式则展示了如何用一个对象来代表整个子系统。

    • 如果你能将对象的所有共享状态简化为一个享元对象， 那么享元就和单例模式类似了。 但这两个模式有两个根本性的不同。

      1. 只会有一个单例实体， 但是享元类可以有多个实体， 各实体的内在状态也可以不同。
      2. 单例对象可以是可变的。 享元对象是不可变的。

    概念示例

    在游戏 《反恐精英》 中， 恐怖分子和反恐精英身着不同类型的衣物。 为了简便起见， 我们就假设双方都各有一种服装类型。 服装对象嵌入在玩家对象之中， 如下所示。

    下面是玩家的结构体。 我们可以看到， 服装对象是嵌入在玩家结构体之中的：

    type player struct {
dress      dress
playerType string // 可为 T 或 CT
lat        int
long       int
}

    假设目前有 5 名恐怖分子和 5 名反恐精英， 一共是 10 名玩家。 那么关于服装， 我们就有两个选项了。

    1. 10 个玩家对象各自创建不同的服装对象， 并将其嵌入。 总共会创建 10 个服装对象。

    2. 我们创建两个服装对象：

    • 单一恐怖分子服装对象： 其将在 5 名恐怖分子之间共享。
    • 单一反恐精英服装对象： 其将在 5 名反恐精英之间共享。

    你可以看到， 方法 1 中我们总共创建了 10 个服装对象； 方法 2 中则只有 2 个服装对象。 第二种方法， 就是我们所遵循的享元设计模式。 我们所创建的 2 个服装对象被称为是享元对象。

    享元模式会从对象中提取出公共部分并创建享元对象。 这些享元对象 （服装） 随后可在多个对象 （玩家） 中分享。 这极大地减少了服装对象的数量， 更棒的是即便你创建了更多玩家， 也只需这么两个服装对象就足够了。

    在享元模式中， 我们会将享元对象存储在 map 容器中。 每当创建共享享元对象的其他对象时， 都会从 map 容器中获取享元对象。

    下面让我们来看看此类安排的内部状态和外部状态：

    • 内部状态： 内部状态的服装可在多个恐怖分子和反恐精英对象间共享。

    • 外部状态： 玩家位置和玩家所使用的武器就是外部状态， 因为其在每个对象中都是不同的。

     dressFactory.go: 享元工厂

    package main

import "fmt"

const (
    //TerroristDressType terrorist dress type
    TerroristDressType = "tDress"
    //CounterTerrroristDressType terrorist dress type
    CounterTerrroristDressType = "ctDress"
)

var (
    dressFactorySingleInstance = &dressFactory{
        dressMap: make(map[string]dress),
    }
)

type dressFactory struct {
    dressMap map[string]dress
}

func (d *dressFactory) getDressByType(dressType string) (dress, error) {
    if d.dressMap[dressType] != nil {
        return d.dressMap[dressType], nil
    }

    if dressType == TerroristDressType {
        d.dressMap[dressType] = newTerroristDress()
        return d.dressMap[dressType], nil
    }
    if dressType == CounterTerrroristDressType {
        d.dressMap[dressType] = newCounterTerroristDress()
        return d.dressMap[dressType], nil
    }

    return nil, fmt.Errorf("Wrong dress type passed")
}

func getDressFactorySingleInstance() *dressFactory {
    return dressFactorySingleInstance
}

     dress.go: 享元接口

    package main

type dress interface {
    getColor() string
}

     terroristDress.go: 具体享元对象

    package main

type terroristDress struct {
    color string
}

func (t *terroristDress) getColor() string {
    return t.color
}

func newTerroristDress() *terroristDress {
    return &terroristDress{color: "red"}
}

     counterTerroristDress.go: 具体享元对象

    package main

type counterTerroristDress struct {
    color string
}

func (c *counterTerroristDress) getColor() string {
    return c.color
}

func newCounterTerroristDress() *counterTerroristDress {
    return &counterTerroristDress{color: "green"}
}

     player.go: 背景

    package main

type player struct {
    dress      dress
    playerType string
    lat        int
    long       int
}

func newPlayer(playerType, dressType string) *player {
    dress, _ := getDressFactorySingleInstance().getDressByType(dressType)
    return &player{
        playerType: playerType,
        dress:      dress,
    }
}

func (p *player) newLocation(lat, long int) {
    p.lat = lat
    p.long = long
}

     game.go: 客户端代码

    package main

type game struct {
    terrorists        []*player
    counterTerrorists []*player
}

func newGame() *game {
    return &game{
        terrorists:        make([]*player, 1),
        counterTerrorists: make([]*player, 1),
    }
}

func (c *game) addTerrorist(dressType string) {
    player := newPlayer("T", dressType)
    c.terrorists = append(c.terrorists, player)
    return
}

func (c *game) addCounterTerrorist(dressType string) {
    player := newPlayer("CT", dressType)
    c.counterTerrorists = append(c.counterTerrorists, player)
    return
}

     main.go: 客户端代码

    package main

import "fmt"

func main() {
    game := newGame()

    //Add Terrorist
    game.addTerrorist(TerroristDressType)
    game.addTerrorist(TerroristDressType)
    game.addTerrorist(TerroristDressType)
    game.addTerrorist(TerroristDressType)

    //Add CounterTerrorist
    game.addCounterTerrorist(CounterTerrroristDressType)
    game.addCounterTerrorist(CounterTerrroristDressType)
    game.addCounterTerrorist(CounterTerrroristDressType)

    dressFactoryInstance := getDressFactorySingleInstance()

    for dressType, dress := range dressFactoryInstance.dressMap {
        fmt.Printf("DressColorType: %s
DressColor: %s
", dressType, dress.getColor())
    }
}

     output.txt: 执行结果

    DressColorType: ctDress
DressColor: green
DressColorType: tDress
DressColor: red
  • 相关阅读:
    MongoDB学习笔记一—简介
    css之定位
    Docker私有仓库1
    Docker安装目录
    Docker 安装完启动服务报错
    Ambari安装组件出错
    Rancher安装使用
    Kettle中spoon.sh在使用时报错
    Kettle jdbc连接hive出现问题
    kettle在linux启动spoon.sh报错
  • 原文地址：https://www.cnblogs.com/rsapaper/p/14696361.html
Copyright © 2020-2023  润新知