。

在这些场景下#xff0c;如果每个对象都独立存在#xff0c…

设计模式14-享元模式

由来动机定义与结构代码推导特点享元模式的应用总结优点缺点使用享元模式的注意事项

由来动机

在很多应用中可能会创建大量相似对象例如在文字处理器中每个字符对象。

在这些场景下如果每个对象都独立存在将会导致巨大的内存开销。

那么如何在避免大量颗粒度对象问题的同时让外部客户程序仍然能够透明的使用面向对象的方式来进行操作呢?享元模式的主要动机是通过共享相似对象来减少内存使用提高系统性能,来解决此类问题。

应用程序使用大量相同或相似对象。

对象的大部分状态可以外部化从而使得许多对象能够共享同一个实例。

需要支持大量细粒度对象高效地共享和复用。

定义与结构

定义了对象的接口可以接受外部状态。

ConcreteFlyweight具体享元

实现Flyweight接口并为内部状态不变部分进行存储。

UnsharedConcreteFlyweight非共享享元

并不是所有的Flyweight子类都需要被共享非共享Flyweight类可以实现Flyweight接口但它们不是共享的。

FlyweightFactory享元工厂

创建并管理Flyweight对象确保合理地共享Flyweight。

代码推导

intrinsicState;public:ConcreteFlyweight(int

state)

flyweights;public:std::shared_ptrFlyweight

getFlyweight(int

std::make_sharedConcreteFlyweight(key);}return

flyweights[key];}

factory;std::shared_ptrFlyweight

fw1

factory.getFlyweight(1);std::shared_ptrFlyweight

fw2

factory.getFlyweight(2);std::shared_ptrFlyweight

fw3

Flyweightfw1-operation(10);fw2-operation(20);fw3-operation(30);return

}特点

将对象的状态分为内部状态和外部状态内部状态存储在享元对象中而外部状态由客户端传入。

不可变性

文本处理

文本编辑器中每个字符都是一个对象通过享元模式共享字符对象减少内存消耗。

图形系统

在图形系统中大量相似的图形对象可以通过享元模式共享例如树木、建筑物等。

缓存

在游戏开发中使用享元模式共享相同类型的游戏对象例如敌人、子弹等减少内存使用。

面对对象很好的解决了抽象性的问题但是作为一个运行在机器中的程序实体我们需要考虑对象的代价问题。

享元模式主要解决面向对象的代价问题,一般不触及面向对象的抽象性问题。

享元模式采用对象共享的方法来降低系统中对象的个数,从而降低细粒度对象给系统带来的内存压力。

在具体实践方面要注意对象状态的处理。

对象的数量太大从而导致对象内存开销加大什么样的数量才算大这需要我们仔细的根据具体应用情况进行评估而不能评空臆断。

减少内存消耗

通过共享细粒度对象享元模式大大减少了内存的使用。

当有大量相似对象需要创建时享元模式特别有效。

提升性能

由于减少了内存使用享元模式可以提升系统的性能特别是在内存有限或系统资源紧张的情况下。

分离内部状态和外部状态

享元模式将对象的状态分为内部状态共享部分和外部状态非共享部分使得对象更加轻量化。

复杂性增加

享元模式引入了额外的复杂性特别是在处理对象状态时需要明确区分内部状态和外部状态。

维护困难

享元模式需要维护一个共享对象的池这增加了代码的复杂性和维护难度。

线程安全问题

在多线程环境下需要确保享元对象的线程安全性可能需要引入额外的同步机制影响性能。

区分内部状态和外部状态

在使用享元模式时需要明确区分哪些状态可以共享内部状态哪些状态是对象独有的外部状态。

适用场景

享元模式适用于有大量相似对象的场景例如图形系统、文本处理、游戏开发等。

如果对象数量不多或者对象之间差异较大使用享元模式的意义不大。

线程安全

在多线程环境下共享的享元对象需要是线程安全的。

可以使用锁例如std::mutex或者其他同步机制确保线程安全。

内存泄漏

享元模式中的享元工厂负责管理共享对象需要确保及时释放不再使用的共享对象以避免内存泄漏。

性能权衡

虽然享元模式可以减少内存使用但也会引入一些性能开销例如对象池的维护、同步机制的使用等。

在设计时需要权衡这些开销。