大家好，这里是每周都在陪你一起进步的网管～！今天继续学习设计模式—享元模式
享元模式是一种结构型设计模式， 它的核心思想是通过共享多个对象所共有的相同状态，从而有效的支持在有限的内存中载入大量细粒度的对象。
这里着重介绍一下享元这个名词，享元可以理解为可复用的对象，即可以是对象级别的复用，也可以是对象的字段进行复用（把可复用的字段单独提炼成一个更精细的对象）。
享元模式的意图是复用对象，节省内存，前提是享元对象是不可变对象，不可变对象指的是初始化之后，对象的状态不会改变了，也就是不会存在被修改的情况。
当一个系统中有大量的重复对象的时候，如果这些对象是不可变对象，我们就可以使用享元模式，将这些对象设计成享元，在内存只保存一份，供需要的代码使用，这样能减少内存中对象的数量，起到节省内存的作用。
实际上，不仅仅相同对象可以设计成享元，对于相似对象，我们也可以将这些对象中相同的部分（字段）提取出来，设计成享元，让这些大量相似对象引用这些享元。
享元模式的实现思路是，在享元对象的工厂类中，通过一个 Map 来缓存已经创建的享元对象，达到复用的目的。接下来我们用一个例子来了解下怎么使用享元模式。
假设我们要设计一个多人在线棋牌游戏的平台。在每个牌局里我们会给用户发牌然后进行对战，如果在平台中每创建一个牌局就需要初始化对应的卡牌，这样显然很浪费，因为一套扑克牌里的卡牌是固定的，不管多少个牌局使用的扑克牌都是一样的，只是牌的玩法不一样。
扑克牌在这里就相当于不可变对象，创建后即不可改变，而牌局是外在对象，有对应的状态变化，我们只需要让每个牌局引用扑克牌这些享元即能达到在有限的内存里多开牌局的目的。
所以我们可以设计一个 pokerCards 存储多个享元扑克牌对象:
var pokerCards = map[int]*Card{
1: {
Name: "A",
Color: "紅",
},
2: {
Name: "A",
Color: "黑",
},
// 其他卡牌
}
type Card struct {
Name string
Color string
}
每个牌局创建时程序会设定牌局里的卡牌都引用自pokerCards中的享元
"本文使用的完整可运行源码
去公众号「网管叨bi叨」发送【设计模式】即可领取"
type PokerGame struct {
Cards map[int]*Card
}
func NewPokerGame() *PokerGame {
board := &PokerGame{Cards: map[int]*Card{}}
for id := range pokerCards {
board.Cards[id] = pokerCards[id]
}
return board
}
具体牌局的规则是什么该怎么打，这些业务逻辑以及牌局的进行状态等这些外部状态都由PokerGame类型来实现，示例代码这里不再过多着墨说明。这里的重点是享元始终是不可改变的，这样才能保证享元在系统中只有一份，起到节省内存的作用。
运行程序我们可以验证，两个牌局都引用了享元，系统中不存在相同享元对象的多次创建。
func main() {
game1 := NewPokerGame()
game2 := NewPokerGame()
fmt.Println(game1.Cards[1] == game2.Cards[1])
}
本文的完整源码，已经同步收录到我整理的电子教程里啦，可向我的公众号「网管叨bi叨」发送关键字【设计模式】领取。
这里享元模式用代码实现的比较简单，主要为了突出享元的不可变，而代表业务当前状态的外部状态都是存储在引用了享元的容器对象中。
下面我们再来用 UML 类图梳理一下享元模式的结构
享元模式的结构中有一下几个角色：
享元模式其实是对象池的一种应用，在应用该模式之前， 我们需要确定程序中确实存在着大量拥有相同状态（字段）的相似对象同时占用内存的问题。
享元模式的优点是能减少对象的创建，降低内存中对象的数量，降低系统的内存，提高效率。其缺点是 我们在写程序时需要关注内、外部状态，关注线程安全问题，使系统、程序的逻辑复杂化。
所以在使用的时候我们需要综合考虑，确定系统存在大量相似对象占用内村过多的问题，这些对象的一些特征字段也确实能提炼成不可变对象作为享元让外部对象进行引用，再考虑使用该模式。
扫码关注公众号「网管叨bi叨」
给网管个星标，第一时间吸我的知识 👆
网管整理了一本《Go 开发参考书》收集了70多条开发实践。去公众号回复【gocookbook】领取！还有一本《k8s 入门实践》讲解了常用软件在K8s上的部署过程，公众号回复【k8s】即可领取！
觉得有用就点个在看 👇👇👇
