Java八股文新考点：丹青识画系统背后的设计模式与架构思想

张

张建站

2026/4/28 3:28:27

10分钟阅读

Java八股文新考点丹青识画系统背后的设计模式与架构思想最近和几个做Java开发的朋友聊天发现大家面试时还在背那些老掉牙的“单例模式有几种写法”、“Spring Bean的生命周期”。不是说这些不重要而是现在的面试官尤其是那些做AI、做中台、做大系统的公司更爱问“你怎么把设计模式用在实际项目里”正好我最近在琢磨一个叫“丹青识画”的AI系统。这名字听着挺文艺其实是个挺复杂的玩意儿——用户上传一张画它能告诉你这是哪个朝代的、什么风格、甚至可能是哪位画家的作品。听起来很酷对吧但更酷的是拆开它的代码你会发现里面全是“八股文”里那些经典设计模式和架构思想的活学活用。今天咱们就抛开枯燥的理论用这个“丹青识画”系统当案例看看那些你背得滚瓜烂熟的设计模式是怎么在真实的、复杂的AI系统里大显身手的。这不仅能帮你应付面试里那些“结合实际”的刁钻问题更能让你真正理解好的代码设计到底长什么样。1. 从需求到架构丹青识画系统概览在开始聊具体的设计模式之前咱们得先搞清楚这个“丹青识画”系统到底要干什么以及它大概是怎么被组织起来的。这就像盖房子得先看明白设计图。想象一下你是个博物馆的工作人员或者是个艺术爱好者手里有张古画的照片但对其一无所知。你希望有个工具能帮你解答几个核心问题这是什么画分类山水、人物、花鸟这像是哪个朝代的断代唐、宋、元、明、清这画风像谁的溯源风格接近吴道子、还是八大山人这画是真的好吗初步鉴定有哪些明显的时代特征或疑点“丹青识画”系统就是为了解决这些问题而生的。它不是一个单一的、庞大的程序而是由一系列小而专的服务协同工作的。这就是典型的微服务架构思想。我们可以把它粗略地拆解成几个核心服务用户上传服务负责接收用户上传的图片进行基本的格式校验、压缩和存储。特征提取服务这是AI的核心。它调用深度学习模型比如ResNet、Vision Transformer等从画作图片中提取出深层的、机器能理解的“特征向量”。这个向量就像画的“数字指纹”。分类鉴定服务它拿着“特征向量”去比对已有的知识库。这个服务内部可能又细分为画种分类器、朝代断代器、风格分析器、画家溯源器等。结果融合与通知服务把各个鉴定器的结果汇总、加权生成一份综合报告然后通知用户。这些服务之间通过轻量级的协议比如HTTP/REST、gRPC进行通信每个服务都可以独立开发、部署和扩展。比如当“风格分析”的模型需要升级时我们只需要更新“特征提取服务”和“风格分析器”而不会影响“朝代断代”的功能。理解了这套架构我们再往里钻看看每个服务内部那些经典的设计模式是如何让代码变得更灵活、更健壮的。2. 工厂模式像流水线一样创建鉴定器现在请求到了“分类鉴定服务”。这个服务需要根据不同的鉴定任务调用不同的“鉴定器”。比如用户想鉴定朝代就调用“朝代断代器”想分析风格就调用“风格分析器”。你可能会想这简单用一堆if...else或者switch不就行了// 一种“简单粗暴”的实现方式 public class IdentificationService { public IdentificationResult identify(String taskType, FeatureVector features) { if (DYNASTY.equals(taskType)) { DynastyIdentifier identifier new DynastyIdentifier(); return identifier.identify(features); } else if (STYLE.equals(taskType)) { StyleIdentifier identifier new StyleIdentifier(); return identifier.identify(features); } else if (AUTHOR.equals(taskType)) { AuthorIdentifier identifier new AuthorIdentifier(); return identifier.identify(features); } // ... 更多的else if throw new UnsupportedTaskTypeException(taskType); } }这段代码跑起来没问题但它有几个明显的“坏味道”违背开闭原则如果明天要新增一个“材质鉴定器”你必须回来修改这个identify方法的代码增加一个新的else if。修改原有代码就带来了风险。职责过重这个服务类既要负责逻辑调度又要负责具体鉴定器的创建耦合度太高。难以管理如果创建鉴定器本身很复杂比如需要加载不同的模型文件、初始化不同的配置这些代码都会堆在这个方法里让代码变得臃肿。这时候工厂模式就该登场了。它的核心思想是将对象的创建过程封装起来与使用它的代码解耦。我们来创建一个“鉴定器工厂”// 1. 首先定义一个所有鉴定器都要实现的接口 public interface ArtIdentifier { IdentificationResult identify(FeatureVector features); String getIdentifierType(); // 返回鉴定器类型如“DYNASTY” } // 2. 实现具体的鉴定器 public class DynastyIdentifier implements ArtIdentifier { private final DynastyModel model; // 可能包含加载好的AI模型 public DynastyIdentifier() { // 初始化例如加载朝代鉴定模型 this.model loadModel(dynasty_model_v2.h5); } Override public IdentificationResult identify(FeatureVector features) { // 调用模型进行推理 DynastyPrediction prediction model.predict(features); return new IdentificationResult(DYNASTY, prediction); } Override public String getIdentifierType() { return DYNASTY; } } // ... 类似的 StyleIdentifier, AuthorIdentifier // 3. 创建工厂类 public class IdentifierFactory { // 可以使用Map来注册和获取鉴定器避免冗长的if-else private static final MapString, ArtIdentifier identifierRegistry new HashMap(); static { // 在静态块中初始化实际项目中可能通过配置或Spring容器注入 registerIdentifier(new DynastyIdentifier()); registerIdentifier(new StyleIdentifier()); registerIdentifier(new AuthorIdentifier()); } private static void registerIdentifier(ArtIdentifier identifier) { identifierRegistry.put(identifier.getIdentifierType(), identifier); } // 工厂方法根据类型获取鉴定器实例 public static ArtIdentifier getIdentifier(String type) { ArtIdentifier identifier identifierRegistry.get(type); if (identifier null) { throw new UnsupportedTaskTypeException(Unsupported identifier type: type); } return identifier; } } // 4. 改造后的服务类变得非常简洁 public class RefinedIdentificationService { public IdentificationResult identify(String taskType, FeatureVector features) { // 直接从工厂获取不关心创建细节 ArtIdentifier identifier IdentifierFactory.getIdentifier(taskType); return identifier.identify(features); } }用了工厂模式之后好处立竿见影服务类 (RefinedIdentificationService) 变得干净它只关心“用什么”和“怎么用”不关心“怎么来”。扩展性极强要新增一个鉴定器你只需要1实现ArtIdentifier接口2在工厂的注册中心比如通过配置文件或注解扫描注册一下。完全不需要修改RefinedIdentificationService的任何代码。这完美符合了“对扩展开放对修改关闭”的开闭原则。创建逻辑可集中管理如果未来创建DynastyIdentifier需要从数据库读取配置或者需要连接远程服务这些复杂的初始化逻辑都可以封装在工厂里对外提供一个干净的接口。在面试里当被问到工厂模式你就可以说“在我们‘丹青识画’系统里工厂模式被用来统一管理各种AI鉴定器的创建。这样业务逻辑层就不需要关心具体的鉴定器是怎么初始化的新增鉴定类型也只需要扩展工厂符合开闭原则大大提升了系统的可维护性。” 这比你干巴巴地背定义要生动有力得多。3. 策略模式灵活切换不同的鉴定算法继续深入。假设我们的“朝代断代器” (DynastyIdentifier) 内部并不是只有一种算法。比如对于明清时期的画我们用一个基于卷积神经网络(CNN)的轻量级模型速度快对于宋元以前的画我们用一个更复杂的、基于Transformer的模型准确率高。用户上传画作后我们可能先用一个简单的预判模型快速判断其大概年代范围然后动态选择最合适的精细鉴定算法。这就像你出门短途骑共享单车长途打车根据距离“策略”选择不同的交通“算法”。如果不用设计模式你可能会在DynastyIdentifier.identify()方法里又写一堆if-else。而策略模式就是为了解决这种“在一个类中定义多种算法或行为并能动态切换”的问题。策略模式定义了一系列算法并将每个算法封装起来使它们可以相互替换。算法的变化不会影响到使用算法的客户。我们来改造一下朝代鉴定器// 1. 定义策略接口所有断代算法都要实现这个接口 public interface DatingStrategy { DynastyPrediction execute(FeatureVector features); } // 2. 实现具体的策略 public class CNNLightweightStrategy implements DatingStrategy { private final LightweightModel model; public CNNLightweightStrategy() { this.model loadCNNModel(); } Override public DynastyPrediction execute(FeatureVector features) { // 快速推理逻辑 return model.quickPredict(features); } } public class TransformerPreciseStrategy implements DatingStrategy { private final PreciseModel model; public TransformerPreciseStrategy() { this.model loadTransformerModel(); } Override public DynastyPrediction execute(FeatureVector features) { // 精确但耗时的推理逻辑 return model.detailedPredict(features); } } // 3. 改造上下文类原来的DynastyIdentifier public class DynastyIdentifier implements ArtIdentifier { private DatingStrategy strategy; // 持有策略的引用 // 可以通过构造器注入策略 public DynastyIdentifier(DatingStrategy strategy) { this.strategy strategy; } // 也可以在运行时动态设置策略 public void setDatingStrategy(DatingStrategy strategy) { this.strategy strategy; } Override public IdentificationResult identify(FeatureVector features) { // 1. 这里可以加入预判逻辑动态选择策略 if (shouldUseLightweightModel(features)) { this.setDatingStrategy(new CNNLightweightStrategy()); } else { this.setDatingStrategy(new TransformerPreciseStrategy()); } // 2. 委托给当前策略执行 DynastyPrediction prediction strategy.execute(features); return new IdentificationResult(DYNASTY, prediction); } private boolean shouldUseLightweightModel(FeatureVector features) { // 基于特征的简单预判逻辑 return features.getEstimatedEra().isAfterMing(); } }策略模式带来的灵活性是巨大的算法独立变化CNNLightweightStrategy和TransformerPreciseStrategy可以独立开发和优化互不影响。消除条件判断DynastyIdentifier的核心方法里不再有冗长的算法选择判断代码更清晰。符合开闭原则未来要新增一种算法比如基于图神经网络的策略只需要新建一个类实现DatingStrategy接口并在合适的地方调用即可无需修改其他策略或上下文类。在实际的AI系统中策略模式的应用场景非常广泛图像预处理策略、特征后处理策略、模型集成策略等等。它让我们的系统不再是铁板一块而是一个可以随时更换“零件”的灵活机器。4. 观察者模式异步通知鉴定结果画作鉴定完了生成了详细的报告。接下来呢系统需要把这个结果“告诉”关心它的各方。通知用户在Web界面或App里弹出结果。存入数据库用于后续的数据分析和模型训练。发送消息可能触发一个微信模板消息或者推送到用户的个人中心。更新缓存如果用户短时间内再次查询同一幅画可以直接从缓存返回结果。触发工作流如果鉴定出是某位重要画家的疑似作品可能需要自动发起一个专家人工复核流程。如果我们这样写代码public class IdentificationResultHandler { public void handleResult(IdentificationResult result) { // 通知用户 notificationService.pushToUser(result.getUserId(), result); // 存入数据库 repository.save(result); // 发送消息 messageQueueService.sendArtIdentifiedMessage(result); // 更新缓存 cacheService.put(result.getImageHash(), result); // 触发工作流 if (result.isPotentialMasterpiece()) { workflowEngine.startExpertReview(result); } // ... 未来再加新的处理逻辑又要来这里修改 } }这又回到了老问题handleResult方法承担了太多职责而且每增加一个对鉴定结果感兴趣的“听众”就要修改这个方法。这违反了单一职责原则也让核心业务逻辑与各种旁路逻辑紧密耦合。观察者模式或发布-订阅模式是处理这种“一对多”依赖关系的利器。它定义了对象间的一种一对多的依赖关系当一个对象主题的状态发生改变时所有依赖于它的对象观察者都会得到通知并自动更新。我们来用观察者模式重构结果处理流程// 1. 定义观察者接口 public interface ResultObserver { void update(IdentificationResult result); } // 2. 实现具体的观察者 public class UserNotifier implements ResultObserver { Override public void update(IdentificationResult result) { // 具体的用户通知逻辑 notificationService.pushToUser(result.getUserId(), result); } } public class ResultPersister implements ResultObserver { Override public void update(IdentificationResult result) { // 数据持久化逻辑 repository.save(result); } } // ... 实现 MessageSender, CacheUpdater, WorkflowTrigger 等 // 3. 定义主题被观察者 public class IdentificationResultSubject { private ListResultObserver observers new ArrayList(); // 注册观察者 public void attach(ResultObserver observer) { observers.add(observer); } // 移除观察者 public void detach(ResultObserver observer) { observers.remove(observer); } // 通知所有观察者 public void notifyObservers(IdentificationResult result) { for (ResultObserver observer : observers) { // 通常在实际项目中这里会采用异步方式避免阻塞 observer.update(result); } } } // 4. 在服务中使用 public class IdentificationResultService { private IdentificationResultSubject resultSubject; public IdentificationResultService() { resultSubject new IdentificationResultSubject(); // 在初始化时注册所有观察者可通过Spring等IoC容器自动装配 resultSubject.attach(new UserNotifier()); resultSubject.attach(new ResultPersister()); resultSubject.attach(new MessageSender()); // ... } public void processResult(IdentificationResult result) { // 核心业务逻辑... // 处理完成后通知所有观察者 resultSubject.notifyObservers(result); } }用了观察者模式之后解耦IdentificationResultService完全不知道有哪些具体的处理逻辑它只负责发布“结果已生成”这个事件。各个处理逻辑观察者也彼此独立。动态订阅可以随时增加新的观察者比如新增一个“数据统计观察者”而无需修改主题或已有观察者的代码。只需要新建一个类实现ResultObserver并在系统启动时注册到主题上即可。易于维护每个观察者只负责一件事符合单一职责原则。在微服务架构下这个模式常常会演进为更彻底的“事件驱动架构”使用消息队列如Kafka、RabbitMQ来作为“主题”各个微服务作为“观察者”去订阅自己关心的事件。这样服务间的耦合度就更低了。5. 不止于模式架构思想与面试思考通过“丹青识画”这个例子我们把工厂、策略、观察者这几个经典模式串了起来。但我想说的是面试官想考察的绝不仅仅是你是否记得这些模式的UML图。他真正想看到的是你理解模式背后的意图你不是在生搬硬套而是能识别出代码中的“坏味道”比如冗长的if-else、频繁的修改并知道用什么模式去解决它。你具备抽象和设计能力你能从一个具体的业务场景中抽象出稳定的接口如ArtIdentifier、DatingStrategy并规划出清晰的依赖关系。你理解架构与模式的结合你知道在微服务、事件驱动等架构下这些模式如何被应用和演化。比如工厂模式可能演化为服务发现与客户端负载均衡观察者模式演化为基于消息队列的事件总线。所以当你在面试中被问到设计模式时可以尝试这样组织你的回答场景切入“在我之前参与/设想的‘丹青识画’这类AI系统中我们遇到了一个XX问题……”让回答有画面感。问题分析“最初的实现是……但这导致了代码臃肿/难以扩展/高度耦合等问题。”展示你识别问题的能力。方案设计“我们引入了XX模式。具体做法是定义了XX接口实现了XX和XX类由XX类负责……。”清晰阐述你的设计。价值总结“这样做之后系统获得了XX好处如符合开闭原则、易于测试、方便扩展并且为后续的XX架构演进如服务化拆分打下了基础。”拔高到设计和架构层面。获取更多AI镜像想探索更多AI镜像和应用场景访问 CSDN星图镜像广场提供丰富的预置镜像覆盖大模型推理、图像生成、视频生成、模型微调等多个领域支持一键部署。