适配器模式解决一个限时返回的接口的场景~

本文介绍了一种优化接口响应时间的方法,通过使用多线程异步处理和CountDownLatch控制同步,结合适配器模式,实现接口在规定时间内响应,无论业务处理是否完成。同时探讨了使用future和DeferredResult的替代方案。

以下虚拟场景:某个接口业务处理耗时不确定,要优化前台交互~

(1)使用多线程异步处理,不管成功与否都返回一个状态,例如正在处理中;

(2)设置限时时常,超时后按业务自定义返回;

我们接下来就是用第二种方式:

1.首先自定义一个抽象类:

public abstract class goRunnable implements Runnable {

        abstract void go();

        private CountDownLatch countDownLatch;

        public goRunnable(CountDownLatch countDownLatch) {
            this.countDownLatch = countDownLatch;
        }

        @Override
        public void run() {
            if (countDownLatch.getCount() != 1) {
                throw new RuntimeException("countDownLatch count should be 1");
            }
            go();
            countDownLatch.countDown();
        }
    }

2.集成抽象类,定义业务方法:

 public class MyTask extends goRunnable {

        public MyTask(CountDownLatch countDownLatch) {
            super(countDownLatch);
        }

        @Override
        void go() {
           //业务.....
        }
    }

3.编写接口:

    @PostMapping("/api")
    public BaseResult api() throws InterruptedException {
        CountDownLatch count = new CountDownLatch(1);
        MyTask task = new MyTask(count);
        ThreadPoolExecutor pool = ThreadPoolUtil.POOL.getPool();
        pool.execute(task);
        //设置超时时长
        boolean await = count.await(1, TimeUnit.SECONDS);
        //根据状态判断返回参数
        return await ? BaseResult.success() : BaseResult.failure("");
    }

 

使用到了适配器模式,并且使用到了CountDownLatch来控制多线程同步,深入了解CountDownLatch及future后可以更底层一点的实现功能~如果你有更好的方法请留言

 

当然还可以使用future来实现类似:

    @Test
    public void t4() throws ExecutionException, InterruptedException {
        ThreadPoolExecutor pool = ThreadPoolUtil.POOL.getPool();
        Future<?> submit = pool.submit(() -> {
            try {
                Thread.sleep(3000);
            } catch (InterruptedException e) {
            }
            System.out.println("测试");
        });
        try {
            submit.get(1, TimeUnit.SECONDS);
        } catch (TimeoutException e) {
            System.out.println("超时");
        }
    }

 

当然还有比较优雅的方式使用DeferredResult

一、实验目的 1.结合所选系统,识别适合引入结构型模式(适配器/装饰器)和行为型模式(观察者/命令)的场景,熟练绘制两种模式的UML结构图。 2.运用Java语言实现模式的核心逻辑,掌握结构型模式“优化对象组合关系”、行为型模式“规范对象交互流程”的编程技巧。 3.通过实践理解:结构型模式如何解决接口不兼容”“功能动态扩展”问题,行为型模式如何解耦“行为发起者与执行者”“状态变化与响应”关系。 二、实验设备 计算机,windows操作系统,MicrosoftVisio,Java开发环境 三、实验内容 系统4:实验室设备管理系统 核心功能: 学生预约/取消预约实验设备; 管理员登记新设备/报废旧设备; 按设备类型(如计算机、显微镜)或可用状态检索设备; 查看某学生的设备预约记录; 查看某设备的历史预约记录(近1个月使用者)。 用户角色: 管理员:负责设备登记/报废、查看所有预约记录; 学生:预约设备、取消自己的预约、查看自己的预约记录。 权限划分: 功能2、5仅管理员可用; 功能1、4仅学生可用(学生只能查看自己的记录); 功能3所有用户可使用。 业务限制: 设备同一时间段只能被一名学生预约; 学生最多同时预约2台设备,单次预约时长不超过4小时; 报废设备不可被预约,且需标注报废时间。 四、实验原理 结构型模式(二选一): 适配器模式:通过定义适配器类,将一个类的接口转换成客户端期望的另一个接口解决“现有组件与新接口不兼容”的问题(如旧系统图书数据格式与新检索接口的适配)。 装饰器模式:通过创建包装对象(装饰器)动态给对象添加额外功能,不改变原有类结构,实现“功能扩展的灵活性”(如给普通订单添加“VIP折扣”“限时促销”等动态功能)。 行为型模式(二选一): 观察者模式:定义对象间的“一对多”依赖关系,当主题对象状态变化时,所有依赖它的观察者自动收到通知并更新(如社团公告发布后,所有成员自动收到消息)。 命令模式:将请求封装为命令对象,使请求发起者(客户端)与执行者(接收者)解耦,支持命令的撤销、排队等功能(如设备预约命令的提交、取消)。 模式协同原则:结构型模式与行为型模式需基于上次实验的创建型模式(单例/工厂)进行扩展,形成“对象创建→结构组合→行为交互”的完整设计链路。 五、实验步骤 任务1:模式选型与结构图设计 结构型模式选型(结合系统痛点): 图书馆系统:若需对接旧书库系统(旧接口OldBookSystem.getBooksByAuthor())与新检索接口(新接口NewSearchService.searchByAuthor())→选适配器模式。 社团系统:若需给社团活动动态添加“线上直播”“签到统计”等功能(不修改原有Activity类)→选装饰器模式。 书店系统:若需给普通订单动态添加“满减优惠”“赠品包装”等功能→选装饰器模式。 实验室系统:若需对接不同品牌设备的控制接口(如BrandAEquipment.start()与BrandBEquipment.powerOn())→选适配器模式。 行为型模式选型(结合系统交互): 图书馆系统:图书上架后需通知所有预约该图书的读者→选观察者模式(图书为主题,读者为观察者)。 社团系统:社团发布公告后需通知所有成员→选观察者模式(社团为主题,成员为观察者)。 书店系统:订单的创建、取消、支付等操作需支持日志记录、撤销→选命令模式(将订单操作封装为命令)。 实验室系统:设备预约、取消预约、延长预约等操作需支持审核、记录→选命令模式(将设备操作封装为命令)。 绘制UML结构图: 结构型模式图:标注核心角色(如适配器模式的“目标接口、适配者、适配器”;装饰器模式的“抽象组件、具体组件、抽象装饰器、具体装饰器”)。 行为型模式图:标注核心角色(如观察者模式的“主题、观察者、具体主题、具体观察者”;命令模式的“命令、接收者、调用者、具体命令”)。 需体现与上次创建型模式的关联(如装饰器模式的“具体组件”由工厂模式创建)。 任务2:Java代码实现 基于选型完成代码实现,要求与原有系统代码(创建型模式部分)兼容。 任务3:系统集成测试 编写测试类,模拟完整业务流程,需体现: 结构型模式与创建型模式的协同(如工厂创建的Book对象通过适配器适配旧系统); 行为型模式对系统交互的优化(如命令模式支持预约撤销,观察者模式自动推送消息); 至少覆盖2个业务场景(如“读者借书→触发图书状态变化→通知预约者”“创建订单→添加VIP折扣→计算总价”)。 六、实验要求 结构图要求: 清晰标注模式各角色的类名、核心方法(如适配器的searchByAuthor()、观察者的update()); 用箭头明确角色关系(如装饰器与被装饰者的“关联”、命令与接收者的“依赖”); 需单独绘制“模式协同图”,展示结构型、行为型与上次创建型模式的调用关系(如单例管理器调用命令对象)。 代码要求: 遵循“开闭原则”:新增模式功能时不修改原有类(如装饰器不修改NormalOrder,适配器不修改OldBookSystem); 接口/抽象类设计合理:结构型模式依赖抽象组件,行为型模式依赖接口定义交互(如Command接口、Observer接口); 代码需包含模式核心逻辑注释(如“此处通过适配器转换旧书数据格式”“此处通知所有观察者”); 与上次实验代码兼容,包结构延续(如com.library.structural放结构型模式类,com.library.behavioral放行为型模式类)。 提交要求: 模式结构图(3个:结构型模式图、行为型模式图、模式协同图,命名格式:学号_姓名_模式类型图); 完整Java代码,需可运行; 实验报告(含模式选型理由、核心代码解释、测试用例与运行结果、模式优缺点分析及与创建型模式的协同效果)。
11-20
MATLAB主动噪声和振动控制算法——对较大的次级路径变化具有鲁棒性内容概要:本文主要介绍了一种在MATLAB环境下实现的主动噪声和振动控制算法,该算法针对较大的次级路径变化具有较强的鲁棒性。文中详细阐述了算法的设计原理与实现方法,重点解决了传统控制系统中因次级路径动态变化导致性能下降的问题。通过引入自适应机制和鲁棒控制策略,提升了系统在复杂环境下的稳定性和控制精度,适用于需要高精度噪声与振动抑制的实际工程场景。此外,文档还列举了多个MATLAB仿真实例及相关科研技术服务内容,涵盖信号处理、智能优化、机器学习等多个交叉领域。; 适合人群:具备一定MATLAB编程基础和控制系统理论知识的科研人员及工程技术人员,尤其适合从事噪声与振动控制、信号处理、自动化等相关领域的研究生和工程师。; 使用场景及目标:①应用于汽车、航空航天、精密仪器等对噪声和振动敏感的工业领域;②用于提升现有主动控制系统对参数变化的适应能力;③为相关科研项目提供算法验证与仿真平台支持; 阅读建议:建议读者结合提供的MATLAB代码进行仿真实验,深入理解算法在不同次级路径条件下的响应特性,并可通过调整控制参数进一步探究其鲁棒性边界。同时可参考文档中列出的相关技术案例拓展应用场景
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值