设计模式之美
王争
前Google工程师,《数据结构与算法之美》专栏作者
立即订阅
21264 人已学习
课程目录
已更新 65 讲 / 共 100 讲
0/6登录后,你可以任选6讲全文学习。
开篇词 (1讲)
开篇词 | 一对一的设计与编码集训,让你告别没有成长的烂代码!
免费
设计模式学习导读 (3讲)
01 | 为什么说每个程序员都要尽早地学习并掌握设计模式相关知识?
02 | 从哪些维度评判代码质量的好坏?如何具备写出高质量代码的能力?
03 | 面向对象、设计原则、设计模式、编程规范、重构,这五者有何关系?
设计原则与思想:面向对象 (11讲)
04 | 理论一:当谈论面向对象的时候,我们到底在谈论什么?
05 | 理论二:封装、抽象、继承、多态分别可以解决哪些编程问题?
06 | 理论三:面向对象相比面向过程有哪些优势?面向过程真的过时了吗?
07 | 理论四:哪些代码设计看似是面向对象,实际是面向过程的?
08 | 理论五:接口vs抽象类的区别?如何用普通的类模拟抽象类和接口?
09 | 理论六:为什么基于接口而非实现编程?有必要为每个类都定义接口吗?
10 | 理论七:为何说要多用组合少用继承?如何决定该用组合还是继承?
11 | 实战一(上):业务开发常用的基于贫血模型的MVC架构违背OOP吗?
12 | 实战一(下):如何利用基于充血模型的DDD开发一个虚拟钱包系统?
13 | 实战二(上):如何对接口鉴权这样一个功能开发做面向对象分析?
14 | 实战二(下):如何利用面向对象设计和编程开发接口鉴权功能?
设计原则与思想:设计原则 (12讲)
15 | 理论一:对于单一职责原则,如何判定某个类的职责是否够“单一”?
16 | 理论二:如何做到“对扩展开放、修改关闭”?扩展和修改各指什么?
17 | 理论三:里式替换(LSP)跟多态有何区别?哪些代码违背了LSP?
18 | 理论四:接口隔离原则有哪三种应用?原则中的“接口”该如何理解?
19 | 理论五:控制反转、依赖反转、依赖注入,这三者有何区别和联系?
20 | 理论六:我为何说KISS、YAGNI原则看似简单,却经常被用错?
21 | 理论七:重复的代码就一定违背DRY吗?如何提高代码的复用性?
22 | 理论八:如何用迪米特法则(LOD)实现“高内聚、松耦合”?
23 | 实战一(上):针对业务系统的开发,如何做需求分析和设计?
24 | 实战一(下):如何实现一个遵从设计原则的积分兑换系统?
25 | 实战二(上):针对非业务的通用框架开发,如何做需求分析和设计?
26 | 实战二(下):如何实现一个支持各种统计规则的性能计数器?
设计原则与思想:规范与重构 (11讲)
27 | 理论一:什么情况下要重构?到底重构什么?又该如何重构?
28 | 理论二:为了保证重构不出错,有哪些非常能落地的技术手段?
29 | 理论三:什么是代码的可测试性?如何写出可测试性好的代码?
30 | 理论四:如何通过封装、抽象、模块化、中间层等解耦代码?
31 | 理论五:让你最快速地改善代码质量的20条编程规范(上)
32 | 理论五:让你最快速地改善代码质量的20条编程规范(中)
33 | 理论五:让你最快速地改善代码质量的20条编程规范(下)
34 | 实战一(上):通过一段ID生成器代码,学习如何发现代码质量问题
35 | 实战一(下):手把手带你将ID生成器代码从“能用”重构为“好用”
36 | 实战二(上):程序出错该返回啥?NULL、异常、错误码、空对象?
37 | 实战二(下):重构ID生成器项目中各函数的异常处理代码
设计原则与思想:总结课 (3讲)
38 | 总结回顾面向对象、设计原则、编程规范、重构技巧等知识点
39 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(上)
40 | 运用学过的设计原则和思想完善之前讲的性能计数器项目(下)
设计模式与范式:创建型 (7讲)
41 | 单例模式(上):为什么说支持懒加载的双重检测不比饿汉式更优?
42 | 单例模式(中):我为什么不推荐使用单例模式?又有何替代方案?
43 | 单例模式(下):如何设计实现一个集群环境下的分布式单例模式?
44 | 工厂模式(上):我为什么说没事不要随便用工厂模式创建对象?
45 | 工厂模式(下):如何设计实现一个Dependency Injection框架?
46 | 建造者模式:详解构造函数、set方法、建造者模式三种对象创建方式
47 | 原型模式:如何最快速地clone一个HashMap散列表?
设计模式与范式:结构型 (8讲)
48 | 代理模式:代理在RPC、缓存、监控等场景中的应用
49 | 桥接模式:如何实现支持不同类型和渠道的消息推送系统?
50 | 装饰器模式:通过剖析Java IO类库源码学习装饰器模式
51 | 适配器模式:代理、适配器、桥接、装饰,这四个模式有何区别?
52 | 门面模式:如何设计合理的接口粒度以兼顾接口的易用性和通用性?
53 | 组合模式:如何设计实现支持递归遍历的文件系统目录树结构?
54 | 享元模式(上):如何利用享元模式优化文本编辑器的内存占用?
55 | 享元模式(下):剖析享元模式在Java Integer、String中的应用
设计模式与范式:行为型 (6讲)
56 | 观察者模式(上):详解各种应用场景下观察者模式的不同实现方式
57 | 观察者模式(下):如何实现一个异步非阻塞的EventBus框架?
58 | 模板模式(上):剖析模板模式在JDK、Servlet、JUnit等中的应用
59 | 模板模式(下):模板模式与Callback回调函数有何区别和联系?
60 | 策略模式(上):如何避免冗长的if-else/switch分支判断代码?
61 | 策略模式(下):如何实现一个支持给不同大小文件排序的小程序?
不定期加餐 (3讲)
加餐一 | 用一篇文章带你了解专栏中用到的所有Java语法
加餐二 | 设计模式、重构、编程规范等相关书籍推荐
春节特别加餐 | 王争:如何学习《设计模式之美》专栏?
免费
设计模式之美
登录|注册

54 | 享元模式(上):如何利用享元模式优化文本编辑器的内存占用?

王争 2020-03-06
上一节课中,我们讲了组合模式。组合模式并不常用,主要用在数据能表示成树形结构、能通过树的遍历算法来解决的场景中。今天,我们再来学习一个不那么常用的模式,享元模式(Flyweight Design Pattern)。这也是我们要学习的最后一个结构型模式。
跟其他所有的设计模式类似,享元模式的原理和实现也非常简单。今天,我会通过棋牌游戏和文本编辑器两个实际的例子来讲解。除此之外,我还会讲到它跟单例、缓存、对象池的区别和联系。在下一节课中,我会带你剖析一下享元模式在 Java Integer、String 中的应用。
话不多说,让我们正式开始今天的学习吧!

享元模式原理与实现

所谓“享元”,顾名思义就是被共享的单元。享元模式的意图是复用对象,节省内存,前提是享元对象是不可变对象。
具体来讲,当一个系统中存在大量重复对象的时候,如果这些重复的对象是不可变对象,我们就可以利用享元模式将对象设计成享元,在内存中只保留一份实例,供多处代码引用。这样可以减少内存中对象的数量,起到节省内存的目的。实际上,不仅仅相同对象可以设计成享元,对于相似对象,我们也可以将这些对象中相同的部分(字段)提取出来,设计成享元,让这些大量相似对象引用这些享元。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《设计模式之美》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(45)

  • Ken张云忠
    1.在棋牌游戏的例子中,有没有必要把 ChessPiecePosition 设计成享元呢?
    没有必要,设计成享元模式主要是为了节省内存资源.
    ChessPiece中的positionX和positionY共占用8个字节,而把ChessPiecePosition设计成享元模式,ChessPiecePosition的引用在ChessPiece中也是占用8个字节,反而还需要额外的内存空间来存放棋盘中各个位置的对象,最终就得不偿失了.
    当启用压缩指针时,ChessPiece对象占用(12+4+4+补4)24个字节,
    当不启用压缩指针时,ChessPiece对象占用(16+4+补4+8)32个字节.
    2.在文本编辑器的例子中,调用 CharacterStyleFactory 类的 getStyle() 方法,需要在 styles 数组中遍历查找,而遍历查找比较耗时,是否可以优化一下呢?
    用map来存储数据CharacterStyle,重写CharacterStyle的hash方法,查找时就创建出新的对象来获取该hash值,用该hash值在map中查找是否存在,如果存在就直接返回,如果不存在就先添加到map中再返回.
    2020-03-06
    5
    25
  • Xion
    1. 没有必要,每局游戏的棋子位置不是完全相同的数据,这取决于用户的输入,随着时间的推移会不断地变化。而使用享元模式保存的数据,应当是那些不变的,会被大量对象复用的数据。
    2.可以考虑使用哈希表保存文本格式,用多出来的一点点空间占用换取O(1)的查询效率。
    2020-03-06
    5
  • 李湘河
    补充一下,对于第二个问题,用LinkedHashMap容器并开启它的LRU策略来装CharacterStyle更好,因为根据一个使用者的习惯,常用的字体风格就是自己最近使用的。
    2020-03-08
    3
  • Wh1
    在避免创建CharacterStyle对象同时,以O(1)的时间复杂度判断CharacterStyle是否已经被创建,代码如下:
    public class CharacterStyleFactory {
        private static final Map<Integer, CharacterStyle> styles = new HashMap<>();

        public static CharacterStyle getStyle(Font font, int size, int colorRGB) {
            //key = font的哈希值 + size + colorRGB 以保证哈希值唯一性, 同时也避免了重复创建CharacterStyle的开销
            int key = font.hashCode() + size + colorRGB;
            if (styles.containsKey(key)) {
                return styles.get(key);
            }
            CharacterStyle newStyle = new CharacterStyle(font, size, colorRGB);
            styles.put(key, newStyle);
            return newStyle;
        }
    }
    2020-03-06
    3
  • 知非
    课后思考题:
    1. position可以使用享元模式,但是对于位置信息而言,两个short类型的整数可以表示, 大量的位置信息也不会占据太多的存储空间,使用享元模式一定程度上增加了代码实现的复杂度,造成move() 方法代码不够直观
    2. 重写CharacterStyle 的hashcode()方法,使用map作为对象池,map的key就是hashcode()的值
    2020-03-06
    1
    3
  • Fstar
    1. 没有必要。棋盘上位置的点集是有限的,是可以设计成享元的。但我们只需要存两个很小的整数,用上享元代码就会变复杂,另外指针也要存储空间。设计成享元可以,但没有必要。

    2. 用哈希表提高查询速度:将 font, size, style 连接为字符串(比如 'yahei-12-123456')作为 hash 表的 key。
    2020-03-07
    2
  • Wh1
    小争哥你好,采用享元模式重构的代码中,CharacterStyleFactory的getStyle()函数是不是设计的有问题。无论styles中是否存在已经创建好的享元对象,都会新建一个CharacterStyle对象。照这么看,styles岂不是根本就没有存在的必要了。
    我认为代码应该改为如下:
    public static CharacterStyle getStyle(Font font, int size, int colorRGB) {
            //遍历styles, 如果styles中有相同对象, 则返回
            for (CharacterStyle style : styles) {
                if (style.equals(font, size, colorRGB)) {
                    return style;
                }
            }
            CharacterStyle newStyle = new CharacterStyle(font, size, colorRGB);
            styles.add(newStyle);
            return newStyle;
        }
    2020-03-06
    3
    2
  • Frank
    打卡 今日学习享元设计模式,收获如下:
    当某个需求中有大量的对象是相似的(或者对象中的某些属性是类似的),且是不可变的,此时可以使用享元设计模式将其进行缓存起来以达到共享使用,节省内存。
    个人觉得享元模式体现了DRY原则,DRY原则是说不要写重复的代码,应用到对象存储方面,可以理解为不要存储相同的数据。
    2020-03-06
    2
  • Jackey
    前面看的时候就在想感觉有点像连接池,当看到一个“共享使用”,一个“重复使用”时真是有种恍然大悟的感觉
    2020-03-06
    2
  • rayjun
    棋牌中的位置也可以设置为享元,因为棋盘上位置个数有限,使用享元也可以节省内存
    2020-03-06
    2
  • Monday
    private void init() {
            chessPieces.put(1, new ChessPiece(
                    ChessPieceUnitFactory.getChessPiece(1), 0,0));
            chessPieces.put(1, new ChessPiece(
                    ChessPieceUnitFactory.getChessPiece(2), 1,0));
            //...省略摆放其他棋子的代码...
        }

    这段代码的第2个put的key应该是2吧
    2020-03-14
    1
  • Heaven

    对于问题一,首先说,围棋棋盘有361个点,如果将位置封装成享元模式,要封装361个对象,如果拥有大量的棋盘去共享这些位置,那么是可以节省内存的,但是我个人倾向于不使用享元,我们来表示位置的数据类型是int,有本身自带的享元对象池,做到了一定的复用,不需要占用太多的内存,而且使用享元对象,在查找享元对象的过程,也需要消耗一定的时间,所以没有必要去为了4个字节浪费那么多的事情
    对于问题二,这就是一个简单的空间换时间的问题,时间耗时长,那么就用一个空间问题来解决,可以使用一个散列表来进行相关的存储,在Java中更是简单,直接使用Map对象即可
    2020-03-12
    1
  • kylexy_0817
    对于第一个问题,个人认为没必要且不能把位置信息设计成享元吧,因为相同棋子在不同的棋局位置都可能不一样
    2020-03-11
    1
  • Jeff.Smile
    要点总结
    1 代码实现主要是通过工厂模式,在工厂类中,通过一个 Map 或者 List 来缓存已经创建好的享元对象,以达到复用的目的。
    2 应用单例模式是为了保证对象全局唯一。应用享元模式是为了实现对象复用,节省内存。缓存是为了提高访问效率,而非复用。池化技术中的“复用”理解为“重复使用”,主要是为了节省时间。
    思考题:
    ①位置在棋盘中组合方式比较多变,不适合做成享元
    ② 可以考虑使用map存放style数据
    2020-03-06
    1
  • 辉哥
    针对于第二个问题,可以重写CharacterStyle的hashCode方法,然后使用hashMap以hashCode为key,CharacterStyle对象为value来缓存。当调用getStyle方法时,先用CharacterStyle对象的hashCode去查找hashMap是否有缓存该对象,有就去判断equals是否为true,为true就返回hashMap中的对象。hashMap查询为null或者equals为false,则把对象加入hashMap中,并返回该对象
    2020-03-22
  • Geek_3b1096
    一直以来误解享元模式==单例
    2020-03-19
  • 传说中的成大大
    关于思考题
    1. 我觉得没得必要 享元模式 最主要的就是保存和共享不可变的对象 对于position这中随时都在变的对象不合适 而且每个棋局的棋子坐标各不相同(享元模式 主要是通过对共同的不可变的对象或者字段进行抽取已达到节省内存的目的)
    2. 从代码上来看 可以把三个条件通过一个hash处理 出一个hash值再做映射 即可达到o(1)
    2020-03-18
  • 茄子
    getStyle() 方法每次都会创建一个新的 CharacterStyle 对象,这代码难道没有问题吗?
    2020-03-17
  • 李小四
    设计模式_54:
    # 作业
    1. 不合适,我看到很多留言分析了内存的占用,说的很有道理,只是享元模式的使用场景是不变的内容,position数据是随着时间变化的,本来直接给position赋值即可,现在要在已知position的情况下,找到value就是position的享元对象,毫无必要的步骤。
    2. 可以使用散列表存储,@李湘河 同学的答案特别好,使用LinkedHashMap并开启LRU策略,很好的细节。

    # 感想
    保证正确的前提下,我们可以根据需求做一些优化:比如为了更快的运行速度多消耗一些内存,也可以为了更小的内存消耗共享不可变对象。
    2020-03-16
  • L🚲🐱
    思考题 1: 没有必要, 因为他们不属于大量重复的对象 2. 可以用 map 存储, 重写 hashcode, 用 hash 作为 key
    2020-03-16
收起评论
45
返回
顶部