过度设计❌:接口方法不合理套用设计模式,导致简单问题复杂化

本文分析了一次过度设计的问题,原本简单的流程处理被错误地应用了状态模式,导致代码结构复杂、可读性下降。通过反思,提出在使用设计模式时要考虑场景,避免将简单问题复杂化。
摘要由CSDN通过智能技术生成

注意⚠️ 本文描述的设计并不合理,可以当做反面案例,下面纯属个人反思。

问题背景

模型搜索算法侧召回出现了badCase,需要对其进行问题排查,以往的人工排查流程划分了很多步骤,现在服务端需要把每一个step的返回值情况串联起来,获得最终的排查结果,流程图结构如下。
在这里插入图片描述


一、基本功能实现

根据流程图所示的描述,创建了一个名称为GroundingSerive的接口和对应实现类,一个核心方法 badCaseDetect( GroundingDTO userInputParam ),在方法内部把流程图描述的所有步骤串联起来。由于步骤真的很多,外加大量if-else结果分支校验的判断,这个方法的代码行数最后接近100行,看上去结构混乱复杂并且可读性差。

修改之前的最初版本代码情况大概是下面这个样子:
在这里插入图片描述

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值