享元模式浅析

Posted 2021-01-12 xiao-lu

源码面前，了无秘密。

 1 package com.xiaolu.flyweightdemotest;
 2 
 3 
 4 import org.junit.Assert;
 5 import org.junit.Test;
 6 
 7 import com.xiaolu.flyweight.FlyweigthtFactory;
 8 import com.xiaolu.flyweight.IChess;
 9 
10 
11 
12 /***
13  * 享元模式：flyweight有轻量的意思。享元即共享。这里的轻量到底指什么？
14  * 
15  * 在享元模式中分为内蕴状态和外蕴状态
16  * 其中：
17  * 1） 内蕴状态是不随环境而改变的，因此可以用用于共享。 （而一个对象中的内蕴状态很少，flyweight更多的表明了这个模式的用途---轻量级对象的共享）
18  * 2） 外蕴状态是随着环境的变化而变化的。外蕴状态一般是由外部传入的。
19  * 
20  * 享元模式定义： 所谓享元模式就是运行共享技术有效地支持大量细粒度对象的复用。   ps: 细粒度（其实也就是因为内蕴状态少，因此对象"小"----可以从内存的观点去考虑）
21  * 使用享元模式的场景是： 当系统需要大量创建对象时，如果能够使用享元模式可以大量节省内存，提高效率。
22  * 
23  * 在这里思考一个问题：为什么是细粒度的？ 也就是为什么是"小"对象（内蕴状态很少的）对象进行共享呢？ 如果多了会如何，内蕴状态多了进行共享不是更能节省内存，享元模式的意义更大吗？
24  *     所谓能够共享，即多个对象内部的状态应当是一样的，否则就谈不上共享。那么如果一个对象的内蕴状态越多，能共享的可能性就越低。【如果有一个对象只有一个属性和有10个属性的对象，哪个更
25  * 容易共享呢？ 如果A、B、C三个客户想要共享，那么如果有10个内蕴状态的，就需要10个属性都一致，A、B、C三个客户才可以共享。而 一个属性的则就方便多了。 当然多个属性的也并非不能共享，
26  * 但是从现实场景考虑-----还是算了】
27  * 
28  * 但是还有一个问题： 是不是属性越少的就可以去使用享元模式进行共享？
29  *     不见得。那怕只有一个属性，但是如果属性的取值范围很大（甚至是任意的），那么享元模式基本上就没什么意义（每次都是创建新的）
30  * 
31  * java中的String类型即使用了享元模式 "abc" == "abc" , 两个相同字符串共享同一个String对象。 ps:但是因为字符串相等，包括长度和顺序，因此如果一个程序中
32  * 没有任何两个字符串是相等的（equals），那么显然也就不能"共享"了。当然从大的范围看，还是有很多情况下，相同字符串多次出现的（否则sun也不傻......)
33  * 
34  * 
35  * 我觉得经典使用享元模式的场景是： 五子棋 （围棋） ， 英文字符的书写。
36  * 五子棋，不管有多少个，都是只有黑白两色。只是分布在不同的位置。因此就可以使用享元模式（白色棋子、黑色棋子共享），而放置的位置信息则可以通过外蕴状态来输入。
37  * 英文字符。26*2 = 52个（大小写），其他的位置、颜色、粗细等，可以通过外部来传入。（否则一篇文章有多长，需要创建多少个对象？一本书呢？哦.....)
38  * 
39  * 
40  * 还有复合享元，下次有时间再看。
41  * 
42  * @author xiaolu 2018年10月11日
43  */
44 public class TestFlyweight {
45     @Test
46     public void test_StringFlyweight() throws Exception {
47         String a = "xiaolu";
48         String b = "xiaolu";
49         Assert.assertTrue(a == b);
50     }
51     
52     
53     @Test
54     public void test_flyweightdemo() throws Exception {
55         IChess black = FlyweigthtFactory.INSTANCE.get("black");// 黑色棋子
56         IChess white = FlyweigthtFactory.INSTANCE.get("white");//白色棋子
57         // 外蕴状态即是位置，通过外部参数传入
58         black.put(10, 10);
59         white.put(100, 100);
60         black.put(12, 12);
61         white.put(30, 30);
62         black.put(15 , 15 );
63         white.put(100, 100);
64         
65         // 因为有工厂的存在不用过多思考，一共创建了2个对象。【就是把black换成FlyweigthtFactory.INSTANCE.get("black")】也没什么区别，除了写起来麻烦。
66     }
67     
68     
69 }

 

 1 package com.xiaolu.flyweight;
 2 
 3 /**
 4  * 享元接口  此接口往往定义了享元对象的提供的行为，将外蕴状态通过行为的参数来传入
 5  * @author xiaolu 2018年10月11日
 6  */
 7 public interface IChess {
 8     
 9     /***
10      * 假设的放置棋子的方法 x, y 分别代表坐标
11      * @param x
12      * @param y
13      */
14     public void put(int x , int y);
15 }

 

 1 package com.xiaolu.flyweight;
 2 
 3 public class Chess implements IChess {
 4     private String color;
 5 
 6     /**
 7      * 网上资料将此处传入的常常称为"外蕴状态"，个人觉得更应该叫做“内蕴状态”或者 "内蕴状态的对应者"
 8      * 没有这种对应，无法知道你想要"共享什么内蕴"的对象。
 9      * 
10      * @author : xiaolu 2018年10月11日
11      */
12     public Chess(String color) {
13         this.color = color;
14     }
15 
16     @Override
17     public void put(int x, int y) {
18         System.out.println(this.color + " 棋 放在 x=" + x + ", y=" + y + "的位置.");
19     }
20 
21 }

 

 1 package com.xiaolu.flyweight;
 2 
 3 import java.util.HashMap;
 4 import java.util.Map;
 5 
 6 /**
 7  * 享元工厂，采用单例实现（此处通过enum来实现，线程安全，规避反序列化-----新学到东西的一次实践）
 8  * ps:莫名就想起了cache----------------
 9  * @author xiaolu 2018年10月11日
10  */
11 public enum FlyweigthtFactory {
12     INSTANCE;
13 
14     private Map<String, IChess> chesses = new HashMap<String, IChess>(2);
15 
16     private FlyweigthtFactory() {
17         chesses.put("black", new Chess("black"));
18         chesses.put("white", new Chess("white"));
19     }
20 
21     /**
22      * 此处有一个有趣的地方：应该使用assert 呢还是，if判断抛异常？
23      * 使用assert ,assert在调试时，打开jre -ea即可起作用，而在产品中则一般不会开启-ea，从而省去了代码检查。关键点在于：
24      *     用户的输入点是需要我们去进行判断的（因为不知道从界面上获取的用户输入会如何-----思维跳出当前这个五子棋吧 ,  ,想想java-web开发，应该在controller就进行输入验证）。而此处逻辑是我们程序
25      * 自己内部调用的，如果此处去检查抛出异常，那么就是前面没有进行错误检查处理。属于程序逻辑设计问题了。
26      * 在开发时内部使用assert，一旦测试通过，则可以忽略掉。毕竟层层检查有时候是无意义并且浪费效率的。（此处也是借鉴了《大道至简》上的思维）
27      * @param color
28      * @return
29      */
30     public IChess get(String color) {
31         assert chesses.containsKey(color);
32         
33         /*
34          * 一般是如此实现----(cache的方式），由于五子棋，我们知道就是黑白两色，因此在构造函数中直接构造，也就不需要此处再去判断加入了。若范围不确定，则需要（就是一般cache的实现思维） 
35          * 
36          * if(!chesses.containsKey(color)){
37          *    chesses.put(color,new Chess(color));
38          *  }
39         */
40         return chesses.get(color);
41     }
42 }