Java设计模式
文章平均质量分 87
大扑棱蛾子
合抱之木,生于毫末;百尺之台,起于垒土;千里之行,始于足下。更多精彩文章请移步我的个人博客:http://jaune162.blog
展开
-
适配器模式(Adapter Pattern)
将一个类的接口转换成客户希望的另外一个接口。Adapter模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作。more。原创 2024-03-13 09:13:32 · 1215 阅读 · 0 评论 -
设计模式系列文章-7个创建型模式更新已完结
博客和专题站内所有内容均免费,由于文章前后书写时思路不一致,导致文章结构也不一致。后续会对文章结构进行调整,统一文章结构。在全部设计模式文章初稿更新玩结构,依然会不断补充和更新新的内容,增加更多工作中的实例和开源框架源码实例,新内容的更新会优先更新到。其实从2019年开始就有些一套关于设计模式的系列文章,但是因为种种原因一直搁置到现在。,博客中的内容更新会有一定的延迟。如果要了解更新更全面的设计模式内容请关注我的。24年2月份开始继续更新设计模式系列文章,目前7个创建型模式已完结。原创 2024-02-26 23:15:45 · 534 阅读 · 0 评论 -
对象池模式-Object Pool Pattern
当对象的创建成本很高并且只在很短的周期内使用,那么对象池模式就很有优势。对象池提供一个对象示例的缓存来跟踪那个对象正在使用,哪个对象是可用的。more对象池其实有点类似于工厂,工厂生产的对象交个客户端后就由客户端来维护其生命周期了。而对象池生产的对象再客户端用完之后还需要还给对象池,对象池中对象的生命周期是由对象池来维护的。对象池的核心操作获取对象:从池中获取一个可用对象,可能会触发对象池的创建动作,创建出一个新的对象。对象归还:在使用完成后归还对象。原创 2024-02-22 22:43:29 · 1054 阅读 · 0 评论 -
简单工厂模式-Simple Factory Pattern
简单工厂模式是一种非常常用的设计模式,但是并不属于GoF中的23种设计模式。简单设计模式有很多种实现方式。本文我们就来讨论简单工厂模式的实现方式,以及如何借助Spring实现一个扩展性很好的简单工厂模式。创建对象但是不想客户端暴露对象实例化的逻辑通过通用接口引用新创建的对象more。原创 2024-02-14 14:48:59 · 997 阅读 · 0 评论 -
工厂方法模式(Factory Method Pattern)
工厂方法模式的优点是,我们知道要一个具体的对象,也知道这个对象的类。但是不用关心谁创建了它,创建的过程如何。在上述日志框架中的应用可以看出,多个工厂其实是冲突的。在实际使用时我们只用一个即可。但是这并不是方法工厂模式的要求,方法工厂模式并没有要求多个工厂不能共存,需要结合实际的应用场景来灵活设计、灵活使用。切勿生搬硬套!原创 2024-02-06 22:08:30 · 1396 阅读 · 0 评论 -
原型模式-Prototype Pattern
用原型实例指定创建对象的种类,并且通过拷贝这些原型创建新的对象。more原型模式就是通过一个以存在的对象来创建另一个。如果对象中存在有字段是对象类型,当这个字段被修改后,会同时影响拷贝和被拷贝对象。这时需要用深拷贝来处理。原创 2024-02-16 22:48:02 · 1218 阅读 · 0 评论 -
抽象工厂模式-Abstract Factory Pattern
首先我们了解下抽象工厂模式的定义。为创建一组相关或相互依赖的对象提供一个接口, 而且无须指定它们的具体类。这个定义不太容易理解,我们通过UML类图和具体的代码来逐步理解其含义。抽象工厂模式是一种创建型设计模式,它提供一个接口用于创建一系列相关或依赖对象的家族,而不需要指定具体的类。这有助于实现对象的解耦和灵活性。适用于需要创建一系列相关对象的场景。它可以提高系统的可维护性和可扩展性。实现了对象的解耦:客户端使用抽象工厂接口来创建产品对象,而无需关心具体的产品类,从而实现了对象的解耦。原创 2024-02-14 14:52:29 · 1142 阅读 · 0 评论 -
建造者模式-Builder Pattern
建造者模式(Builder Pattern)是一种创建型设计模式,它可以让你构建复杂对象时更加灵活和可控。这种模式的主要目的是将一个复杂对象的构建与它的表示分离,使得同样的构建过程可以创建不同的表示。在软件开发中,我们经常会遇到一些复杂的对象,这些对象通常由多个部分组成,而且每个部分的创建和组合可能需要花费大量的时间和精力。为了解决这个问题,我们可以使用建造者模式来简化对象的构建过程。建造者模式的核心思想是将复杂对象的构建过程分解为多个简单的步骤,每个步骤负责创建一个特定的部分。原创 2024-02-16 22:51:41 · 1078 阅读 · 0 评论 -
设计原则之-接口隔离原则(Interface Segregation Principle, ISP)
定义Clients should not be forced to depend upon interfaces that they don’t use.客户端不应该依赖那些它不需要的接口核心思想记得几年前有一位很厉害的前辈说过:软件设计是什么,就是“分离关注点,消除重复”。这句话一直影响这我,而我做软件设计也是朝着这两个方向努力。而接口隔离原则最核心的就是拆分,即分离关注点。实例...原创 2019-03-18 16:52:13 · 684 阅读 · 1 评论 -
设计原则之-依赖倒置原则(Dependency Inversion Principle, DIP)
定义High-level modules should not depend on low-level modules. Both should depend on abstractions.Abstractions should not depend on details. Details should depend on abstractions.高层模块不应该依赖于低层模块,两者...原创 2019-03-18 16:51:21 · 496 阅读 · 1 评论 -
设计原则之-里氏替换原则(Liskov‘s Substitution Principle,LSP)
定义里氏替换原则是Barbara Liskov1与1988年提出来的。原文是:What is wanted here is something like the following substitution property: If for each object of type S there is an object of type T such that for all program...原创 2019-03-18 16:50:21 · 410 阅读 · 1 评论 -
设计原则之-开闭原则(Open Close Principle, OCP)
定义Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification软件实体(类、模块、函数等)应该对扩展开放,对修改关闭。核心思想开闭原则的核心思想就是抽象。开闭原则的主要目的就是为了让我们在不修改源码的情况下来扩展系统的功能。...原创 2019-03-18 16:48:57 · 449 阅读 · 0 评论 -
设计原则之--单一职责原则(Single Responsibility Principle, SRP)
1、核心思想定义A class should have only one reason to change. ( 就一个类而言,应该仅有一个引起它变化的原因)每一个职责都是变化的一个轴线(an axis of change)。当需求变化时,该变化会反映为类的职责变化。如果一个类承担了多于一个的职责,那么引起它变化的原因就会有多个。如果一个类承担的职责过多,就等于把这些职责耦合在了一起...原创 2019-02-25 17:17:38 · 469 阅读 · 0 评论 -
设计模式之单例模式--懒汉模式与饿汉模式(2)
上一章讲了单例模式的基本实现方式,但是在多线程环境下,这种方式是存在严重的问题的。所以本章我们就来解决多线程环境的问题。懒汉模式利用方法锁实现一种方式是在获取实例的方法上加锁// 代码清单1public class LazyInstantiationConfigUtils { private static Logger logger = LoggerFactory.getLo...原创 2019-02-22 16:10:39 · 211 阅读 · 0 评论 -
设计模式之单例模式--简单单例模式(1)
使用场景:需要在系统中确保类只有一个实例,一般这种类的创建都会比较占用系统资源。比如配置文件初始化,将配置文件中的数据读取到类中,通常需要耗费一定的系统资源,而且配置文件中的内容一般都是不变的,修改完配置文件一般都会要求重启系统。所以这种类最适合使用单例模式简单单例模式实现/** * 简单的单例模式 * * @author 大扑棱蛾子 * @since 1.0.0 */pu...原创 2019-02-22 16:09:40 · 196 阅读 · 0 评论 -
设计模式六大原则
原文地址:http://www.cnblogs.com/lhws/archive/2012/03/10/2389189.html单一职责原则(Single Responsibility Principle)定义:不要存在多于一个导致类变更的原因。通俗的说,即一个类只负责一项职责。问题由来:类T负责两个不同的职责:职责P1,职责P2。当由于职责P1需求发生改变而需要修改类转载 2014-10-01 16:39:54 · 1149 阅读 · 1 评论