以下文章内容来源:微信公众号(Java知音)文章,设计模式是什么鬼(享元)

首先来看一个实例,比如我们要开发一款RPG游戏,游戏地图通常非常大,而且有各种各样,有草地、沙漠、荒原,水路等等,在写代码之前,我们先思考下应该怎样去建模。

享元模式
享元模式

对于这种地图,我们加载一整张图片来做地图?如果地图太大,图片加载相当卡顿吧?而且大片地图上其实都是重复的图片素材,整图加载设计也有失灵活性。再仔细观察下,这地图无非就是很多小图片(元)拼起来的哦,这不就是类似于我们装修时贴马赛克嘛?

简单的实现方法,我们有个砖块类,持有“图片”,“位置”等属性信息,然后实例化这些砖块再调用其“绘制”方法把图片显示在地图某位置上即可。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
public class Tile {

private String image;//地砖所用的图片材质
private int x, y;//地砖所在坐标

public Tile(String image, int x, int y) {
this.image = image;
System.out.print("从磁盘加载[" + image + "]图片,耗时半秒。。。");
this.x = x;
this.y = y;
}

public void draw() {
System.out.println("在位置[" + x + ":" + y + "]上绘制图片:[" + image + "]");
}

}

代码看起来非常简单,第3行的地砖材质图片我们用String来模拟代替,第7行初始化时我们把图片加载到内存,比如说这个IO操作要耗费半秒时间,好了我们先测试绘制第一行砖块,运行一下。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
public class Client {
public static void main(String[] args) {
//以绘制第一行为例
new Tile("河流", 10, 10).draw();
new Tile("河流", 10, 20).draw();
new Tile("石路", 10, 30).draw();
new Tile("草坪", 10, 40).draw();
new Tile("草坪", 10, 50).draw();
new Tile("草坪", 10, 60).draw();
new Tile("草坪", 10, 70).draw();
new Tile("草坪", 10, 80).draw();
/* 运行结果
从磁盘加载[河流]图片,耗时半秒。。。在位置[10:10]上绘制图片:[河流]
从磁盘加载[河流]图片,耗时半秒。。。在位置[10:20]上绘制图片:[河流]
从磁盘加载[石路]图片,耗时半秒。。。在位置[10:30]上绘制图片:[石路]
从磁盘加载[草坪]图片,耗时半秒。。。在位置[10:40]上绘制图片:[草坪]
从磁盘加载[草坪]图片,耗时半秒。。。在位置[10:50]上绘制图片:[草坪]
从磁盘加载[草坪]图片,耗时半秒。。。在位置[10:60]上绘制图片:[草坪]
从磁盘加载[草坪]图片,耗时半秒。。。在位置[10:70]上绘制图片:[草坪]
从磁盘加载[草坪]图片,耗时半秒。。。在位置[10:80]上绘制图片:[草坪]
*/
}
}

有没有发现问题?每加载一张图都要耗费掉半秒钟,才画了8张地砖图就4秒钟流逝了,如果构建整张地图得多少时间?这就像是在慢性自杀,如此效率严重影响了游戏的用户体验,光卡顿在地图加载这给漫长的过程就已经让玩家失去兴趣了。

这个场景很容易想到用原型模式来实现,把相同的图共享出来,用克隆的方式代替物件图实例化的过程,从而加快初始化速度。共享元貌似没什么问题,速度也加快了,但对象数量貌似还是个严重问题,每一个小物件图都要对应一个对象,这么个小游戏用得着那么大的内存开销么,搞不好甚至会造成内存溢出,所以,设计模式一定还是有问题。

假装有图
假装有图

沿着共享的思路我们再看下到底需不需要这么多对象?这些对象不同的地方在于其坐标的不同,再就是材质的不同,也就是图的不同了,能不能从这些对象里抽取出来一些共同点呢?首先每个图的坐标都不一样,是没办法共享的,但是材质图是重复出现的,是可以共享的,同样的材质图会在不同的坐标位置上重复出现,那么这个材质图是可以做成共享元的。

既然坐标不能共享,那就不做为材质类的共享元属性,由客户端维护这些坐标并作为参数传入好了,而且这些材质都有绘制能力,那就先定义一个接口吧。

1
2
3
4
5
public interface Drawable {

void draw(int x, int y);//绘制方法,接收地图坐标。

}

也可以用抽象类抽出更多的属性和方法代替接口,使子类变得简单,这里为了清晰说明问题就用接口。接下来是材质类们,统统实现这个绘制接口。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Water implements Drawable {

private String image;//河流图片材质

public Water() {
this.image = "河流";
System.out.print("从磁盘加载[" + image + "]图片,耗时半秒。。。");
}

@Override
public void draw(int x, int y) {
System.out.println("在位置[" + x + ":" + y + "]上绘制图片:[" + image + "]");
}

}

注意第6行因为是河流材质类,所以初始化我们直接加载河流图片素材,这就是类内部即将做共享的“元”数据了,也叫做“内蕴状态”,至于“外蕴状态”就是坐标了,只作为参数从外部传入不做共享。接下来是草地、石子路等等。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Grass implements Drawable {

private String image;//草坪图片材质

public Grass() {
this.image = "草坪";
System.out.print("从磁盘加载[" + image + "]图片,耗时半秒。。。");
}

@Override
public void draw(int x, int y) {
System.out.println("在位置[" + x + ":" + y + "]上绘制图片:[" + image + "]");
}

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
public class Stone implements Drawable {

private String image;//石路图片材质

public Stone() {
this.image = "石路";
System.out.print("从磁盘加载[" + image + "]图片,耗时半秒。。。");
}

@Override
public void draw(int x, int y) {
System.out.println("在位置[" + x + ":" + y + "]上绘制图片:[" + image + "]");
}

}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
public class House implements Drawable {

private String image;//房子图片材质

public House() {
this.image = "房子";
System.out.print("从磁盘加载[" + image + "]图片,耗时一秒。。。");
}

@Override
public void draw(int x, int y) {
System.out.println("将图层切到最上层。。。");//房子盖在地上,所以切换到顶层图层。
System.out.println("在位置[" + x + ":" + y + "]上绘制图片:[" + image + "]");
}

}

注意上面这个的房子类有所不同,它有自己特有的绘制行为方法,也就是在地板图层之上绘制房子,覆盖掉下面的地板,使其变得更加立体。这也就是为什么我们非要用接口或抽象类来做引用,使实现类可以有自己独特的行为方式,多态的好处立竿见影。接下来就是实现“元之共享”的关键了,我们来做一个简单工厂类,看代码。

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
public class Factory {//图件工厂
private Map<String, Drawable> images;//图库

public Factory() {
images = new HashMap<String, Drawable>();
}

public Drawable getDrawable(String image) {
//缓存里如果没有图件,则实例化并放入缓存。
if(!images.containsKey(image)){
switch (image) {
case "河流":
images.put(image, new Water());
break;
case "草坪":
images.put(image, new Grass());
break;
case "石路":
images.put(image, new Stone());
}
}
//缓存里必然有图,直接取得并返回。
return images.get(image);
}
}

这个图件工厂维护着所有元对象的图库,构造方法于第5行会初始化一个哈希图的缓存”池“,当客户端于第8行需要实例化图件的时候,我们先观察这个图库池里存在不存在已实例化过的图件,也就是看有无已做共享的图元,如果没有则实例化并加入图库共享池供下次使用,这便是”元之共享“的秘密了。巧夺天工的设计一气呵成,已经迫不及待去运行了。

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
public class Client {
public static void main(String[] args) {
//先实例化图件工厂
Factory factory = new Factory();
//以第一行为例
factory.getDrawable("河流").draw(10, 10);
factory.getDrawable("河流").draw(10, 20);
factory.getDrawable("石路").draw(10, 30);
factory.getDrawable("草坪").draw(10, 40);
factory.getDrawable("草坪").draw(10, 50);
factory.getDrawable("草坪").draw(10, 60);
factory.getDrawable("草坪").draw(10, 70);
factory.getDrawable("草坪").draw(10, 80);
/*运行结果
从磁盘加载[河流]图片,耗时半秒。。。在位置[10:10]上绘制图片:[河流]
在位置[10:20]上绘制图片:[河流]
从磁盘加载[石路]图片,耗时半秒。。。在位置[10:30]上绘制图片:[石路]
从磁盘加载[草坪]图片,耗时半秒。。。在位置[10:40]上绘制图片:[草坪]
在位置[10:50]上绘制图片:[草坪]
在位置[10:60]上绘制图片:[草坪]
在位置[10:70]上绘制图片:[草坪]
在位置[10:80]上绘制图片:[草坪]
*/
}
}

可以看到,我们抛弃了利用new关键字肆意妄为地制造对象,而是改用这个图件工厂去帮我们把元构建并共享起来。显而易见,我们看到运行结果中每次实例化对象会耗费半秒时间,再次请求对象时就不再会加载图片耗费时间了,也就是从共享图池直接拿到了,不再造次。更妙的是,如果画完整个地图只需要实例化需要用到的某些元素材而已,即使是那个大房子图件也只需要实例化一次就够了。至此,CPU速度,内存轻量化同时做到了优化,整个游戏用户体验得到了极大的提升。

享元的精髓当然重点不止于”享“,更重要的是对于元的辨识,例如那个从外部客户端传入的坐标参数,如果我们依然把坐标也当作共享对象元数据(内蕴状态)的话,那么这个结构将无元可享,大量的对象就如同世界上没有相同的两片树叶一样多不胜数,最终会导致图库池被撑爆,享元将变得毫无意义。所以,对于整个系统数据结构的分析、设计、规划显得尤为重要。