享元模式主要是为了复用对象,节省内存。使用享元模式需要有两个前提:
- 享元对象不可变:当享元模式创建出来后,它的变量和属性不会被修改
- 系统中存在大量重复对象:这些重复对象可以使用同一个享元,内存中只存在一份,这样会节省大量空间。当然这也是为什么享元对象不可变的原因,因为有很多引用,变更的话会引起很多问题。 UML类图位置:https://www.processon.com/diagraming/609b375407912943913a4c13
本文代码链接为:https://github.com/shidawuhen/asap/blob/master/controller/design/17flyweight.go
1.定义
1.1享元模式
享元模式:运用共享技术有效的支持大量细粒度的对象。
UML:
1.2分析
享元模式主要是把系统中共同的、不变的对象抽象出来,达到共用一份的效果。
抽象出的对象接口为Flyweight,ConcreteFlyweight为实际被共享的对象。UnsharedConcreteFlyweight是否存在,主要看是否有对象是无需共享的。
享元模式里有工厂FlyweightFactory,主要是因为系统中需要的享元结构虽然确定了,但是享元的属性不同,所以需要管理多个对象,此处使用了工厂模式。关于工厂模式可以参看这篇文章Go设计模式(7)-工厂模式。
2.使用场景
享元模式还是有很多具体使用场景的,如很多联网类棋牌游戏。假设有100w场象棋游戏在同时进行,不使用享元模式的话,系统需要维护32*100w个象棋对象。但象棋的文案、颜色、规则是不变的,变的只是持有人和位置。所以将32个象棋对象抽象出来,当做享元,可以极大的节省空间,而且不会带来成本提升。
享元模式与其说是一种设计模式,不如说是一种设计理念,主要讲的是抽象的能力,将相同模块提取出来,供不同模块使用。从这个维度来说,代码重构中提取相同功能、单例模式等,何尝不是另一种享元。
3.代码实现
写一下象棋游戏中对于象棋的管理吧。
1 | package main |
输出:
➜ myproject go run main.go
创建房间1,玩家为66和88
初始化棋盘
玩家66的棋子为
兵,颜色为红,规则为过河前只能一步一步前进,过河后只能一步一步前进或者左右移位置为(1,1)
玩家88的棋子为
兵,颜色为黑,规则为过河前只能一步一步前进,过河后只能一步一步前进或者左右移位置为(16,1)
3总结
享元模式充分说明了抽象的重要性,希望大家能够善用这种模式,优化系统。