享元(Flyweight)模式的定义:运用共享技术来有效地支持大量细粒度对象的复用。它通过共享已经存在的对象来大幅度减少需要创建的对象数量、避免大量相似类的开销,从而提高系统资源的利用率。
享元模式是对象池的一种利用.
优点:
- 缩小对象的创立,升高内存中对象的数量,升高零碎的内存,提高效率。
- 缩小内存之外的其余资源占用。
缺点:
- 为了使对象可以共享,需要将一些不能共享的状态外部化,这将增加程序的复杂性。
- 读取享元模式的外部状态会使得运行时间稍微变长。
享元模式的结构与实现
享元模式的定义提出了两个要求,细粒度和共享对象。因为要求细粒度,所以不可避免地会使对象数量多且性质相近,此时我们就将这些对象的信息分为两个部分:内部状态和外部状态。
- 内部状态指对象共享出来的信息,存储在享元信息内部,并且不回随环境的改变而改变;
- 外部状态指对象得以依赖的一个标记,随环境的改变而改变,不可共享。
比如,连接池中的连接对象,保存在连接对象中的用户名、密码、连接URL等信息,在创建对象的时候就设置好了,不会随环境的改变而改变,这些为内部状态。而当每个连接要被回收利用时,我们需要将它标记为可用状态,这些为外部状态。
享元模式的本质是缓存共享对象,降低内存消耗。
1. 模式的结构
享元模式的主要角色有如下。
- 抽象享元角色(Flyweight):是所有的具体享元类的基类,为具体享元规范需要实现的公共接口,非享元的外部状态以参数的形式通过方法传入。
- 具体享元(Concrete Flyweight)角色:实现抽象享元角色中所规定的接口。
- 非享元(Unsharable Flyweight)角色:是不可以共享的外部状态,它以参数的形式注入具体享元的相关方法中。
- 享元工厂(Flyweight Factory)角色:负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检査系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话,则创建一个新的享元对象。
从下面所示,其中:
- UnsharedConcreteFlyweight 是非享元角色,里面包含了非共享的外部状态信息 info;
- Flyweight 是抽象享元角色,里面包含了享元方法 operation(UnsharedConcreteFlyweight state),非享元的外部状态以参数的形式通过该方法传入;
- ConcreteFlyweight 是具体享元角色,包含了关键字 key,它实现了抽象享元接口;
- FlyweightFactory 是享元工厂角色,它是关键字 key 来管理具体享元;
- 客户角色通过享元工厂获取具体享元,并访问具体享元的相关方法。
案例:
场景
- 某火车票查问, 可依据发站和到站, 查问余票信息
- 火车票蕴含根本信息(发站, 到站, 经停站, 登程工夫, 到站工夫…)和剩余票数信息
- 根本信息字段较多, 且只跟发站和到站相干, 因而可采纳享元模式进行池化解决
- 残余票数信息因为实时变动, 因而由余票服务另外提供
设计
- ITicket: 定义车票根本信息接口
- ITicketRemaining: 继承ITicket, 并增加余票数信息
- ITicketService: 定义车票信息服务接口
- ITicketRemainingService: 定义余票信息服务接口. 依据发站和到站, 查问余票信息.
- tMockTicket: 车票信息实体, 实现ITicket接口
- tMockTicketService: 车票信息服务, 通过享元模式池化了车票信息.
- tMockTicketRemaining: 余票信息实体, 实现ITicketRemaining接口
- tMockTicketRemainingService: 余票信息服务, 通过ITicketService获取车票根本信息. 依据发站和到站, 查问余票信息.
单元测试
flyweight_pattern_test.go
package structural_patterns
import (
"learning/gooop/structural_patterns/flyweight"
"testing"
)
func Test_FlyweightPattern(t *testing.T) {
from := "福田"
to := "广州南"
ticket := flyweight.NewMockTicket(1, from, to, 100)
flyweight.MockTicketService.Save(ticket)
flyweight.MockTicketRemainingService.Save(ticket.ID(), 10)
remaining := flyweight.MockTicketRemainingService.Get(from, to)
t.Logf("from=%s, to=%s, price=%v, remaining=%v\n", remaining.From(), remaining.To(), remaining.Price(), remaining.Remaining())
}
测试输入
t$ go test -v flyweight_pattern_test.go
=== RUN Test_FlyweightPattern
flyweight_pattern_test.go:16: from=福田, to=广州南, price=100, remaining=10
--- PASS: Test_FlyweightPattern (0.00s)
PASS
ok command-line-arguments 0.003s
ITicket.go
定义车票根本信息接口
package flyweight
// 车票信息
type ITicket interface {
ID() int
From() string
To() string
LeavingTime() string
ArrivalTime() string
InterList() []string
Price() float64
}
ITicketRemaining.go
继承ITicket, 并增加余票数信息
package flyweight
// 余票信息
type ITicketRemaining interface {
ITicket
Remaining() int
}
ITicketService.go
定义车票信息服务接口
package flyweight
type ITicketService interface {
Get(from string, to string) ITicket
Save(it ITicket)
}
ITicketRemainingService.go
定义余票信息服务接口, 依据发站和到站, 查问余票信息.
package flyweight
type ITicketRemainingService interface {
Get(from string, to string) ITicketRemaining
Save(id int, num int)
}
tMockTicket.go
车票信息实体, 实现ITicket接口
package flyweight
import "strings"
type tMockTicket struct {
iID int
sFrom string
sTo string
sLeavingTime string
sArrivalTime string
mInterList []string
fPrice float64
iRemaining int
}
func NewMockTicket(id int, from string, to string, price float64) *tMockTicket {
return &tMockTicket{
iID: id,
sFrom: from,
sTo: to,
sLeavingTime: "09:00",
sArrivalTime: "11:30",
mInterList: strings.Split("深圳北,虎门", ","),
fPrice: price,
}
}
func (me *tMockTicket) ID() int {
return me.iID
}
func (me *tMockTicket) From() string {
return me.sFrom
}
func (me *tMockTicket) To() string {
return me.sTo
}
func (me *tMockTicket) LeavingTime() string {
return me.sLeavingTime
}
func (me *tMockTicket) ArrivalTime() string {
return me.sArrivalTime
}
func (me *tMockTicket) InterList() []string {
return me.mInterList
}
func (me *tMockTicket) Price() float64 {
return me.fPrice
}
tMockTicketService.go
车票信息服务, 实现ITicketService接口, 通过享元模式池化了车票信息.
package flyweight
import "sync"
type tMockTicketService struct {
mTickets map[string]ITicket
mRWMutex *sync.RWMutex
}
func newMockTicketService() *tMockTicketService {
return &tMockTicketService{
make(map[string]ITicket, 0),
new(sync.RWMutex),
}
}
func (me *tMockTicketService) Get(from string, to string) ITicket {
k := from + "-" + to
me.mRWMutex.RLock()
defer me.mRWMutex.RUnlock()
it,ok := me.mTickets[k]
if ok {
return it
} else {
return nil
}
}
func (me *tMockTicketService) Save(it ITicket) {
k := it.From() + "-" + it.To()
me.mRWMutex.Lock()
defer me.mRWMutex.Unlock()
me.mTickets[k] = it
}
var MockTicketService ITicketService = newMockTicketService()
tMockTicketRemaining.go
余票信息实体, 实现ITicketRemaining接口
package flyweight
type tMockTicketRemaining struct {
ITicket
iRemaining int
}
func newMockTicketRemaining(it ITicket, num int) *tMockTicketRemaining {
return &tMockTicketRemaining{
it, num,
}
}
func (me *tMockTicketRemaining) Remaining() int {
return me.iRemaining
}
tMockTicketRemainingService.go
余票信息服务, 实现ITicketRemainingService接口. 通过ITicketService获取车票根本信息. 依据发站和到站, 查问余票信息.
package flyweight
import "sync"
type tMockTicketRemainingService struct {
mRemaining map[int]int
mRWMutex *sync.RWMutex
}
func newMockTicketRemainingService() *tMockTicketRemainingService {
return &tMockTicketRemainingService{
make(map[int]int, 16),
new(sync.RWMutex),
}
}
func (me *tMockTicketRemainingService) Get(from string, to string) ITicketRemaining {
ticket := MockTicketService.Get(from, to)
if ticket == nil {
return nil
}
r := newMockTicketRemaining(ticket, 0)
me.mRWMutex.RLock()
defer me.mRWMutex.RUnlock()
num,ok := me.mRemaining[ticket.ID()]
if ok {
r.iRemaining = num
}
return r
}
func (me *tMockTicketRemainingService) Save(id int, num int) {
me.mRWMutex.Lock()
defer me.mRWMutex.Unlock()
me.mRemaining[id] = num
}
var MockTicketRemainingService ITicketRemainingService = newMockTicketRemainingService()
享元模式的应用场景
当系统中多处需要同一组信息时,可以把这些信息封装到一个对象中,然后对该对象进行缓存,这样,一个对象就可以提供给多出需要使用的地方,避免大量同一对象的多次创建,降低大量内存空间的消耗。
享元模式其实是工厂方法模式的一个改进机制,享元模式同样要求创建一个或一组对象,并且就是通过工厂方法模式生成对象的,只不过享元模式为工厂方法模式增加了缓存这一功能。
前面分析了享元模式的结构与特点,下面分析它适用的应用场景。享元模式是通过减少内存中对象的数量来节省内存空间的,所以以下几种情形适合采用享元模式。
- 系统中存在大量相同或相似的对象,这些对象耗费大量的内存资源。
- 大部分的对象可以按照内部状态进行分组,且可将不同部分外部化,这样每一个组只需保存一个内部状态。
- 由于享元模式需要额外维护一个保存享元的数据结构,所以应当在有足够多的享元实例时才值得使用享元模式。
享元模式的扩展
在前面介绍的享元模式中,其结构图通常包含可以共享的部分和不可以共享的部分。在实际使用过程中,有时候会稍加改变,即存在两种特殊的享元模式:单纯享元模式和复合享元模式,下面分别对它们进行简单介绍。
(1) 单纯享元模式,这种享元模式中的所有的具体享元类都是可以共享的,不存在非共享的具体享元类,其结构图如下所示。
(2) 复合享元模式,这种享元模式中的有些享元对象是由一些单纯享元对象组合而成的,它们就是复合享元对象。虽然复合享元对象本身不能共享,但它们可以分解成单纯享元对象再被共享,其结构图如下 所示。