java设计模式-建造者模式
将一个复杂对象的构建与表示分离,使得同样的构建过程可以创建不同的表示。
- 分离了部件的构造(由Builder来负责)和装配(由Director负责)。 从而可以构造出复杂的对象。这个模式适用于:某个对象的构建过程复杂的情况。
- 由于实现了构建和装配的解耦。不同的构建器,相同的装配,也可以做出不同的对象;相同的构建器,不同的装配顺序也可以做出不同的对象。也就是实现了构建算法、装配算法的解耦,实现了更好的复用。
- 建造者模式可以将部件和其组装过程分开,一步一步创建一个复杂的对象。用户只需要指定复杂对象的类型就可以得到该对象,而无须知道其内部的具体构造细节。
建造者(Builder)模式包含如下角色:
- 抽象建造者类(Builder):这个接口规定要实现复杂对象的那些部分的创建,并不涉及具体的部件对象的创建。
- 具体建造者类(ConcreteBuilder):实现 Builder 接口,完成复杂产品的各个部件的具体创建方法。在构造过程完成后,提供产品的实例。
- 产品类(Product):要创建的复杂对象。
- 指挥者类(Director):调用具体建造者来创建复杂对象的各个部分,在指导者中不涉及具体产品的信息,只负责保证对象各部分完整创建或按某种顺序创建。
类图如下:
不喜欢看文字的朋友可以看教程↓设计模式,讲解的很清楚,而且举得例子也蛮恰当的。是从设计模式的一些相关的概念开始,再到软件设计原则,重点讲解23种设计模式,针对每一种模式都配备了相关的代码。最后通过一个综合案例将常用的设计模式使用起来。 和市面上设计模式的教程,这套课程不同的是 从基础开始。只要你有JavaSE的基础都可以学习全面。针对设计模式及其模式的变形及开发中是如何使用的 案例经典。学习spring框架是最好的提升的途径,spring框架将面向对象体现的淋漓尽致。
实例:创建共享单车
生产自行车是一个复杂的过程,它包含了车架,车座等组件的生产。而车架又有碳纤维,铝合金等材质的,车座有橡胶,真皮等材质。对于自行车的生产就可以使用建造者模式。
这里Bike是产品,包含车架,车座等组件;Builder是抽象建造者,MobikeBuilder和OfoBuilder是具体的建造者;Director是指挥者。类图如下:
具体的代码如下:
注意:
上面示例是 Builder模式的常规用法,指挥者类 Director 在建造者模式中具有很重要的作用,它用于指导具体构建者如何构建产品,控制调用先后次序,并向调用者返回完整的产品类,但是有些情况下需要简化系统结构,可以把指挥者类和抽象建造者进行结合
说明:
这样做确实简化了系统结构,但同时也加重了抽象建造者类的职责,也不是太符合单一职责原则,如果construct() 过于复杂,建议还是封装到 Director 中。
优点:
- 建造者模式的封装性很好。使用建造者模式可以有效的封装变化,在使用建造者模式的场景中,一般产品类和建造者类是比较稳定的,因此,将主要的业务逻辑封装在指挥者类中对整体而言可以取得比较好的稳定性。
- 在建造者模式中,客户端不必知道产品内部组成的细节,将产品本身与产品的创建过程解耦,使得相同的创建过程可以创建不同的产品对象。
- 可以更加精细地控制产品的创建过程 。将复杂产品的创建步骤分解在不同的方法中,使得创建过程更加清晰,也更方便使用程序来控制创建过程。
- 建造者模式很容易进行扩展。如果有新的需求,通过实现一个新的建造者类就可以完成,基本上不用修改之前已经测试通过的代码,因此也就不会对原有功能引入风险。符合开闭原则。
缺点:
造者模式所创建的产品一般具有较多的共同点,其组成部分相似,如果产品之间的差异性很大,则不适合使用建造者模式,因此其使用范围受到一定的限制。
建造者(Builder)模式创建的是复杂对象,其产品的各个部分经常面临着剧烈的变化,但将它们组合在一起的算法却相对稳定,所以它通常在以下场合使用。
- 创建的对象较复杂,由多个部件构成,各部件面临着复杂的变化,但构件间的建造顺序是稳定的。
- 创建复杂对象的算法独立于该对象的组成部分以及它们的装配方式,即产品的构建过程和最终的表示是独立的。
建造者模式除了上面的用途外,在开发中还有一个常用的使用方式,就是当一个类构造器需要传入很多参数时,如果创建这个类的实例,代码可读性会非常差,而且很容易引入错误,此时就可以利用建造者模式进行重构。
重构前代码如下:
上面在客户端代码中构建Phone对象,传递了四个参数,如果参数更多呢?代码的可读性及使用的成本就是比较高。
重构后代码:
重构后的代码在使用起来更方便,某种程度上也可以提高开发效率。从软件设计上,对程序员的要求比较高。
工厂方法模式注重的是整体对象的创建方式;而建造者模式注重的是部件构建的过程,意在通过一步一步地精确构造创建出一个复杂的对象。
我们举个简单例子来说明两者的差异,如要制造一个超人,如果使用工厂方法模式,直接产生出来的就是一个力大无穷、能够飞翔、内裤外穿的超人;而如果使用建造者模式,则需要组装手、头、脚、躯干等部分,然后再把内裤外穿,于是一个超人就诞生了。
抽象工厂模式实现对产品家族的创建,一个产品家族是这样的一系列产品:具有不同分类维度的产品组合,采用抽象工厂模式则是不需要关心构建过程,只关心什么产品由什么工厂生产即可。
建造者模式则是要求按照指定的蓝图建造产品,它的主要目的是通过组装零配件而产生一个新产品。
如果将抽象工厂模式看成汽车配件生产工厂,生产一个产品族的产品,那么建造者模式就是一个汽车组装工厂,通过对部件的组装可以返回一辆完整的汽车。
Java设计模式-单例模式
单例模式定义:它确保一个类只有一个实例,并提供一个全局访问点来访问该实例。
单例模式主要分为两大类:饿汉式和懒汉式,懒汉式又分为 单线程下的普通懒汉式,多线程下的双重校验锁、静态内部类、枚举。
单例模式的应用场景举例:
配置管理器:当应用程序需要读取和维护配置信息时,通常会使用单例模式来创建一个配置管理器。这保证了整个应用中只有一份配置数据副本,所有组件都引用同一个配置对象,从而避免了数据不一致的问题。
日志记录器:单例模式确保在整个应用程序中只有一个日志记录器实例。这样,所有的日志消息都可以统一地被这个实例处理。
单例模式确保在整个应用程序中只有一个日志记录器实例。这样,所有的日志消息都可以统一地被这个实例处理。例如,在 Java 中,java.util.logging.Logger类可以通过单例模式来实现。开发人员可以通过Logger.getLogger(\”name\”)方法获取一个唯一的日志记录器实例,所有对该实例的调用都可以保证日志的一致性,比如记录不同模块的信息到同一个日志文件中。
缓存:缓存数据通常需要全局唯一的实例来管理,以便在不同的地方访问和修改缓存时保持一致性。
单例模式可以用于实现缓存。一个单例的缓存实例可以存储经常访问的数据,在整个应用程序享。例如,一个 Web 应用中的用户权限缓存。当用户登录后,系统会查询数据库获取用户的权限信息并存储在单例缓存中。在用户后续的操作中,如访问某个需要权限验证的页面时,系统可以直接从这个单例缓存中获取用户权限信息,而不是每次都去查询数据库,大大提高了系统的响应速度。
数据库连接池:
数据库连接是一个昂贵的操作,频繁地创建和销毁连接会消耗大量的系统资源。因此,通常会使用连接池来管理数据库连接,而连接池本身往往是一个单例,以确保在整个应用中只有一个连接池实例,优化数据库访问性能。
线程池:
当处理大量并发任务时,为每个任务创建一个新线程会导致系统资源耗尽。线程池可以预先创建一组线程,任务到来时,将任务分配给线程池中的线程来执行,任务执行完毕后线程可以被复用。
单例模式适用于线程池的实现。整个应用程序通常只需要一个线程池来管理线程资源。例如,在 Java 的ExecutorService框架中,通过Executors.newFixedThreadPool(n)创建一个固定大小的线程池,这个线程池可以作为一个单例存在于应用程序中。所有需要异步执行的任务都可以提交给这个单例线程池,它可以有效地管理线程的创建、分配和回收,提高系统的并发处理能力。
单例模式的优点:
- 控制实例数量:确保一个类只有一个实例,避免了实例的重复创建,节省系统资源。
- 全局访问点:提供一个全局访问点,使得访问该实例变得简单。
- 延迟加载:某些实现方式(如懒汉式单例)可以实现延迟加载,即在需要时才创建实例,从而提高系统性能。
- 资源共享和节省:单例模式确保在整个应用程序中只有一个实例存在。对于一些资源密集型的对象,如数据库连接池、线程池等,这可以避免创建多个相同的对象,从而节省系统资源。
(一)单例模式-饿汉式java样例
(二)单例模式-单线程下-懒汉式java样例
(三)单例模式-多线程下-双重校验锁java样例
(四)单例模式-静态内部类
(五)单例模式-枚举
本文作者及来源:Renderbus瑞云渲染农场https://www.renderbus.com
文章为作者独立观点不代本网立场,未经允许不得转载。