Java设计模式-享元模式

简介: Java设计模式-享元模式

微信截图_20220524205657.png


继续啦继续啦,学习不能断哦。继组合模式后开启了享元模式啦。 会了就当复习丫,不会来一起来看看吧。

很喜欢一句话:“八小时内谋生活,八小时外谋发展”。

如果你也喜欢,让我们一起坚持吧!!

共勉😁


一张旧图


设计模式系列


一、享元模式前言


1)引入:


在Java中,我们都知道在创建字符串对象时,都需要去字符串常量池中寻找一番,已经有了,就不再重复创建了,只是把它的引用指向那个地址,没有就再创建。


因为如果每一次都去创建新的字符串对象的话,内存开销会非常大,所以说享元模式是池技术的重要实现方式。


2)概述:


享元模式(Flyweight Pattern)主要用于减少创建对象的数量,以减少内存占用和提高性能。这种类型的设计模式属于结构型模式,它提供了减少对象数量从而改善应用所需的对象结构的方式.


享元模式尝试重用现有的同类对象,如果未找到匹配的对象,则创建新对象。


3)结构:


享元(Flyweight )模式中存在以下两种状态:


  1. 内部状态,即不会随着环境的改变而改变的可共享部分。


  1. 外部状态,指随环境改变而改变的不可以共享的部分。享元模式的实现要领就是区分应用中的这两种状态,并将外部状态外部化。


享元模式的主要有以下角色:


  • 抽象享元角色(Flyweight):通常是一个接口或抽象类,在抽象享元类中声明了具体享元类公共的方法,这些方法可以向外界提供享元对象的内部数据(内部状态),同时也可以通过这些方法来设置外部数据(外部状态)。


  • 具体享元(Concrete Flyweight)角色 :它实现了抽象享元类,称为享元对象;在具体享元类中为内部状态提供了存储空间。通常我们可以结合单例模式来设计具体享元类,为每一个具体享元类提供唯一的享元对象。


  • 非享元(Unsharable Flyweight)角色 :并不是所有的抽象享元类的子类都需要被共享,不能被共享的子类可设计为非共享具体享元类;当需要一个非共享具体享元类的对象时可以直接通过实例化创建。


  • 享元工厂(Flyweight Factory)角色 :负责创建和管理享元角色。当客户对象请求一个享元对象时,享元工厂检査系统中是否存在符合要求的享元对象,如果存在则提供给客户;如果不存在的话,则创建一个新的享元对象。


4)使用场景:


1、系统有大量相似对象。


2、需要缓冲池的场景。


如果一个应用程序使用了大量的对象,而这些对象造成了很大的存储开销的时候就可以考虑是否可以使用享元模式。


例如,如果发现某个对象的生成了大量细粒度的实例,并且这些实例除了几个参数外基本是相同的,如果把那些共享参数移到类外面,在方法调用时将他们传递进来,就可以通过共享大幅度单个实例的数目


二、案例代码


案例:俄罗斯方块


下面的图片是众所周知的俄罗斯方块中的一个个方块,如果在俄罗斯方块这个游戏中,每个不同的方块都是一个实例对象,这些对象就要占用很多的内存空间,下面利用享元模式进行实现。


微信截图_20220524205901.png


我们玩俄罗斯方块大都数是这些方块形状,出现不同也只是颜色的不一样,那么这样我们就可以把他们共有的东西,抽取出来。


类图:


微信截图_20220524205925.png


俄罗斯方块有不同的形状,这里我只描述了其中几个,其他的都相同,就不再写出来了。

”I" 、"J"、"L"就拿这三个字符来表示俄罗斯方块了哈😁😁,更详细的在代码中含有解释。


我们在AbstractBox 中定义了public abstract String getShape();,这个是将形状再向上抽象一层。


IBox、LBox、OBox继承分别实现了getShape()方法,表示不一样的形状。这在享元模式的状态中,属于内部状态。


外部状态就是各种形状的颜色。


代码:


详细的看下面的代码:


俄罗斯方块有不同的形状,我们可以对这些形状向上抽取出AbstractBox,用来定义共性的属性和行为。


public abstract class AbstractBox {
    public abstract String getShape();
    public void display(String color) {
        System.out.println("方块形状:" + this.getShape() + " 颜色:" + color);
    }
}


不同的形状了,IBox类、LBox类、OBox类


public class IBox extends AbstractBox {
    @Override
    public String getShape() {
        return "I";
    }
}
public class LBox extends AbstractBox {
    @Override
    public String getShape() {
        return "L";
    }
}
public class OBox extends AbstractBox {
    @Override
    public String getShape() {
        return "O";
    }
}


提供了一个工厂类(BoxFactory),用来管理享元对象(也就是AbstractBox子类对象),该工厂类对象只需要一个,所以可以使用单例模式。并给工厂类提供一个获取形状的方法。


public class BoxFactory {
    private static HashMap<String, AbstractBox> map;
    // 在构造方法中进行初始化操作
    private BoxFactory() {
        map = new HashMap<String, AbstractBox>();
        map.put("I", new IBox());
        map.put("L", new LBox());
        map.put("O", new OBox());
    }
    //提供一个方法获取工厂类对象
    public static final BoxFactory getInstance() {
        return SingletonHolder.INSTANCE;
    }
    // 静态内部类的方式来实现单例模式
    private static class SingletonHolder {
        private static final BoxFactory INSTANCE = new BoxFactory();
    }
    //根据名字获取图形对象
    public AbstractBox getBox(String key) {
        return map.get(key);
    }
}


客户端:


public class Client {
    public static void main(String[] args) {
        BoxFactory boxFactory = BoxFactory.getInstance();
        AbstractBox box = boxFactory.getBox("I");
        box.display("黄色");
        AbstractBox box2 = boxFactory.getBox("I");
        box2.display("绿色");
        System.out.println(box==box2);
        System.out.println(box.equals(box2));
        /**
         * 方块形状:I 颜色:黄色
         * 方块形状:I 颜色:绿色
         * true
         * true
         */
    }
}


我们可以看到两个对象虽然颜色不一样,但是两个对象却是一样的。实现了公用。


三、总结


1、优点


  • 极大减少内存中相似或相同对象数量,节约系统资源,提高系统性能


  • 享元模式中的外部状态相对独立,且不影响内部状态


2、缺点:


为了使对象可以共享,需要将享元对象的部分状态外部化,分离内部状态和外部状态,使程序逻辑复杂


提高了系统的复杂度,需要分离出外部状态和内部状态,而且外部状态具有固有化的性质,不应该随着内部状态的变化而变化,否则会造成系统的混乱。


3、使用场景:


  • 一个系统有大量相同或者相似的对象,造成内存的大量耗费。


  • 对象的大部分状态都可以外部化,可以将这些外部状态传入对象中。


  • 在使用享元模式时需要维护一个存储享元对象的享元池,而这需要耗费一定的系统资源,因此,应当在需要多次重复使用享元对象时才值得使用享元模式。


4、应用实例:


String常量池


数据库连接池


四、自言自语


微信截图_20220524210115.png


你好,如果你正巧看到这篇文章,并且觉得对你有益的话,就给个赞吧,让我感受一下分享的喜悦吧,蟹蟹。🤗


如若有写的有误的地方,也请大家不啬赐教!!


同样如若有存在疑惑的地方,请留言或私信,定会在第一时间回复你。


持续更新中


目录
相关文章
|
2月前
|
设计模式 消息中间件 搜索推荐
Java 设计模式——观察者模式:从优衣库不使用新疆棉事件看系统的动态响应
【11月更文挑战第17天】观察者模式是一种行为设计模式,定义了一对多的依赖关系,使多个观察者对象能直接监听并响应某一主题对象的状态变化。本文介绍了观察者模式的基本概念、商业系统中的应用实例,如优衣库事件中各相关方的动态响应,以及模式的优势和实际系统设计中的应用建议,包括事件驱动架构和消息队列的使用。
|
2月前
|
设计模式 Java 数据库连接
Java编程中的设计模式:单例模式的深度剖析
【10月更文挑战第41天】本文深入探讨了Java中广泛使用的单例设计模式,旨在通过简明扼要的语言和实际示例,帮助读者理解其核心原理和应用。文章将介绍单例模式的重要性、实现方式以及在实际应用中如何优雅地处理多线程问题。
40 4
|
3月前
|
设计模式 Java 程序员
[Java]23种设计模式
本文介绍了设计模式的概念及其七大原则,强调了设计模式在提高代码重用性、可读性、可扩展性和可靠性方面的作用。文章还简要概述了23种设计模式,并提供了进一步学习的资源链接。
58 0
[Java]23种设计模式
|
2月前
|
设计模式 JavaScript Java
Java设计模式:建造者模式详解
建造者模式是一种创建型设计模式,通过将复杂对象的构建过程与表示分离,使得相同的构建过程可以创建不同的表示。本文详细介绍了建造者模式的原理、背景、应用场景及实际Demo,帮助读者更好地理解和应用这一模式。
|
3月前
|
设计模式 监控 算法
Java设计模式梳理:行为型模式(策略,观察者等)
本文详细介绍了Java设计模式中的行为型模式,包括策略模式、观察者模式、责任链模式、模板方法模式和状态模式。通过具体示例代码,深入浅出地讲解了每种模式的应用场景与实现方式。例如,策略模式通过定义一系列算法让客户端在运行时选择所需算法;观察者模式则让多个观察者对象同时监听某一个主题对象,实现松耦合的消息传递机制。此外,还探讨了这些模式与实际开发中的联系,帮助读者更好地理解和应用设计模式,提升代码质量。
Java设计模式梳理:行为型模式(策略,观察者等)
|
4月前
|
存储 设计模式 安全
Java设计模式-备忘录模式(23)
Java设计模式-备忘录模式(23)
|
4月前
|
设计模式 存储 算法
Java设计模式-命令模式(16)
Java设计模式-命令模式(16)
|
4月前
|
设计模式 存储 缓存
Java设计模式 - 解释器模式(24)
Java设计模式 - 解释器模式(24)
|
4月前
|
设计模式 安全 Java
Java设计模式-迭代器模式(21)
Java设计模式-迭代器模式(21)
|
4月前
|
设计模式 缓存 监控
Java设计模式-责任链模式(17)
Java设计模式-责任链模式(17)