设计模式怎样落到具体项目？

返回 架构与 SDK 目录

标准回答

策略模式可隔离不同显示目标或检索执行策略，适配器可统一 MDE、模型供应方或外部接口差异，状态模式适合流转和任务生命周期。观察者适合订阅状态，但要明确取消和线程，避免事件总线使依赖不可追踪。

依赖注入让组件依赖接口和明确构造参数，而非到处读取全局单例。单例适合真正的进程级无状态或受控资源，不能持有跨账户、跨页面的随意状态。工厂应表达创建策略，不必为每个简单对象都增加层级。

判断抽象质量可以改变一个条件：增加一个屏幕能力、切换 Embedding 服务、增加一种错误处理，观察修改是否局限在对应边界。若每次仍要改所有层，模式名称再多也没有真正隔离变化。

追问与回答

为什么不全部采用微服务

网络、部署、观测和数据一致性都有成本。清晰模块可以先在同一进程实现，独立故障与伸缩需求成熟时再拆。

如何避免过度设计

围绕已经存在或明确即将出现的变化点抽象，保留简单路径；用实际维护成本评估而非用类数量衡量架构。

易混淆点

• 先选设计模式，再强迫业务适应它。

内容来源

• Android 与 AI 工程 Wiki · 原条目 q201