- 博客(116)
- 资源 (2)
- 收藏
- 关注
RSS订阅原创 中介者模式：对象之间网状耦合，怎么拆
当多个对象之间相互调用、相互依赖，形成复杂网状耦合时，如何用一个中介对象集中协调它们之间的交互。它不是为了凭空多加一个“管理类”。多个对象互相持有引用协作规则散落在各个对象里修改联动逻辑需要改很多类模块之间出现循环依赖对象职责越来越不清楚多模块联动越来越难测试系统关系从简单链条变成复杂网络中介者模式的重点不是“所有对象都找一个中心”，而是“把对象之间复杂的网状交互，收敛成清晰的协调逻辑”。智能座舱场景模式联动HMI 多组件协作空调、座椅、车窗、灯光、音响协同控制。
2026-07-01 22:48:37
194
原创 责任链模式：多级校验、多级处理如何优雅串起来
当一个请求需要经过多个处理节点，并且每个节点都有机会处理、放行或拦截时，如何把这些处理逻辑优雅地串起来。它不是为了把简单if-else强行拆成很多类。多级校验全部堆在一个函数里多级处理顺序不清楚新增处理步骤必须修改核心逻辑相同校验逻辑在多个业务里复制某一级失败后需要中断后续流程不同业务想复用同一批处理节点链路需要按车型、业务、配置灵活组合责任链模式的重点不是“把代码拆成一串类”，而是“让每个节点只负责自己那一关，请求按链路逐级传递”。远程车控指令校验和执行诊断请求处理链。
2026-06-29 22:36:40
235
原创 模板方法模式：流程固定、步骤变化时怎么设计
父类定义模板方法，也就是固定流程。Step1();Step2();Step3();其中某些步骤由父类实现，某些步骤由子类实现。当一个业务流程整体固定，但其中某些步骤会变化时，如何复用流程骨架，并把变化点交给子类实现。它不是为了炫耀继承。多个类有相同的处理流程流程顺序必须保持一致某些步骤在不同子类中实现不同公共校验、日志、异常处理不想重复写不希望子类随意改变关键流程新增实现时只关注变化步骤模板方法模式的重点不是“把公共代码放父类”，而是“父类固定流程，子类实现变化步骤”。
2026-06-24 22:33:10
255
原创 命令模式：把请求封装成对象，有什么实际价值
当一次请求需要被传递、排队、记录、撤销、重试、异步执行或统一调度时，如何把请求封装成对象。它不是为了把简单函数调用复杂化。请求发送者和执行者强耦合请求需要排队和异步执行请求需要日志、审计和追踪请求需要撤销和重做请求需要失败重试和统一调度请求类型越来越多，if-else 越来越长请求需要作为测试步骤或任务单元被组合命令模式的重点不是“把函数包成类”，而是“让请求变成可以被管理的对象”。远程车控指令HMI 用户操作OTA 下载 / 校验 / 安装任务诊断请求执行。
2026-06-22 21:36:22
211
原创 观察者模式：多模块通知怎么解耦
当一个对象变化后，需要通知多个模块，但又不希望发布者直接依赖所有订阅者时，如何解耦通知关系。它不是简单地“回调一下”。一个模块变化后有多个响应方发布者不应该依赖具体订阅者新增订阅者不应该频繁修改发布者多模块通知逻辑不应该塞进主流程事件响应应该由订阅者自己负责系统需要更清晰的一对多通知机制观察者模式的重点不是“通知别人”，而是“发布者只发布事件，不依赖具体接收方”。车辆信号变化通知OTA 状态和进度通知告警事件通知诊断结果通知配置变化通知网络状态变化通知。
2026-06-17 08:30:00
424
原创 状态模式：如何设计一个真正可维护的状态机
当对象在不同状态下行为不同，并且状态之间会发生流转时，如何让状态机更可维护。它不是简单地把枚举换成类。状态判断越来越多事件处理越来越复杂状态转换规则散落进入和退出动作混乱非法事件处理不清楚Context 被状态逻辑污染状态机难测试、难排查、难扩展状态模式的重点不是“把状态写成类”，而是“让当前状态自己决定如何处理事件以及如何流转”。OTA 升级状态机充电状态机诊断会话状态机电源模式状态机车门锁状态机自动驾驶功能状态机蓝牙连接状态机远程控制任务状态机。
2026-06-15 08:30:00
305
原创 策略模式：如何把越来越多的 if-else 拆掉
当一个行为有多种算法或规则时，如何把它们从主流程里拆出来，并让它们可以互相替换。它不是为了消灭所有 if-else。一个函数里塞满多种算法分支数量越来越多新增规则必须修改核心逻辑不同算法互相影响单元测试边界不清楚主流程被大量细节污染策略模式的重点不是“没有 if-else”，而是“把可替换的算法封装成独立策略”。驾驶模式策略能量回收策略告警处理策略诊断响应校验策略OTA 下载 / 校验 / 安装策略路径规划策略热管理控制策略数据上报策略。
2026-06-12 08:30:00
154
原创 享元模式：对象太多时，怎么节省内存
诊断系统里，DTC 定义和 DID 定义通常比较稳定。DTC 编号DTC 名称故障描述严重等级恢复条件具体诊断结果只需要保存状态、时间和上下文。当系统里存在大量相似对象时，如何通过共享重复状态来节省内存。它不是简单地写一个缓存。对象数量巨大对象内部有大量重复数据重复元数据导致内存浪费对象创建和管理成本较高元数据复制多份后难以保持一致高并发、高频采集、高频仿真场景下内存压力明显享元模式的重点不是“复用对象”，而是“共享对象里那些不变的重复状态”。
2026-06-10 08:30:00
196
原创 组合模式：树形结构如何统一处理
组合模式只解决结构。一个子节点失败，是否继续？是否收集所有错误？是否按优先级执行？是否支持跳过？这些不要等出问题再补。当对象是树形结构时，如何统一处理单个对象和组合对象。它不是为了让代码看起来更抽象。树形结构到处手写递归调用方不断判断节点类型叶子节点和组合节点无法统一处理整体和部分的边界不清楚新增节点类型会影响大量调用方菜单、配置、诊断、权限、场景等层级对象难维护组合模式的重点不是“把对象放进 vector”，而是“让整棵树和单个节点看起来像同一种对象”。HMI 菜单树。
2026-06-08 08:30:00
214
原创 桥接模式：抽象和实现如何分别变化
也就是高层业务抽象。OtaServiceHmiWidget它定义的是调用方真正关心的业务能力。也就是抽象层的进一步扩展。它们可以在高层业务上继续扩展，而不需要关心底层实现细节。抽象和实现都有可能变化时，如何让它们分别变化，而不是互相绑死。它不是为了让代码多一层接口。两个变化维度被揉在一起继承层次随着组合数量膨胀抽象层被底层实现细节污染新增实现时需要修改大量业务类新增业务时需要复制大量底层实现代码平台化、多车型、多供应商场景下扩展困难。
2026-06-05 08:30:00
185
原创 外观模式：复杂子系统为什么要有统一入口
复杂子系统不应该直接裸露给调用方，而应该通过一个统一、高层、易用的入口来提供服务。它不是为了改接口兼容性，也不是为了动态增强功能，更不是为了控制某个对象的访问。子系统功能很多，但对上层太难用调用顺序复杂，容易用错重复的流程编排散落在各处内部实现会演进，但对外接口最好稳定业务层不应该承受太多技术细节外观模式的重点不是“替谁做决定”，而是“帮调用方把复杂性收起来”。诊断子系统统一入口OTA 升级流程统一入口仿真平台启动入口数据采集任务入口HIL / 台架资源管理入口。
2026-06-03 08:30:00
226
原创 代理模式：控制访问，而不是增强功能
上一篇讲了装饰器模式。它解决的问题是：不改原类，怎么在外面一层层包起来，给对象动态加上日志、重试、统计、缓存、故障注入这些附加能力。但真实工程里，还有一类问题，看起来也像“包一层”，本质却完全不一样。这类问题不是：我想给原对象多加点功能。而是：我不想让调用方直接碰原对象，我想先控制一下它怎么被访问。这就是代理模式要解决的事。
2026-06-01 08:30:00
227
原创 装饰器模式：不改原类，怎么给功能动态加能力
前面说过，装饰顺序会影响行为。两者日志粒度不同。如果项目里没有明确约定，后期会出现很多细小但难排查的问题。不修改原类，也能动态地给对象增加额外能力。它不是为了让代码看起来更复杂。原类不应该被日志、重试、统计等横切逻辑污染继承会导致功能组合类爆炸不同环境需要不同能力组合新增增强能力时，不希望反复修改核心类附加能力应该有清晰归属装饰器模式的重点不是“换接口”，而是“保持接口不变，在外面叠加能力”。通信链路增加日志、重试、trace、指标统计诊断服务增加权限校验、安全访问、耗时统计。
2026-05-29 08:30:00
161
原创 知行合一：为什么懂了很多道理，还是很难做到？
知行合一没有那么玄。它不是让我们成为圣人，也不是要求我们从此不犯错。别让道理永远停在嘴上。你懂早睡，就今晚早点放下手机。你懂运动，就今天先走二十分钟。你懂学习，就现在翻开书看几页。你懂珍惜时间，就少刷一会儿无意义的信息。你懂要改变，就先把眼前那件小事做了。真正的知行合一，不是知道一百分才行动。而是知道一分，就先做到一分。做到一分，生活就往前走一分。很多改变，都是这样慢慢发生的。
2026-05-27 08:30:00
412
原创 适配器模式：新老接口不兼容时怎么优雅接起来
这不是一定不行。但如果层次太多、命名不清、边界混乱，排查问题会很痛苦。所以模式能组合，但组合之后要能读得懂。当已有类的接口和当前系统需要的接口不兼容时，用一层适配把它们优雅地接起来。它不是为了让类图更复杂。新老接口不一致第三方 SDK 风格不统一历史实现不能直接接入新抽象参数、返回值、数据结构需要转换业务层不应该承担接口翻译细节适配器模式的重点不是“重写老代码”，而是“把老代码接到新接口体系里”。新老供应商接口适配CAN / DoIP / 串口统一封装历史模块接入新平台。
2026-05-26 22:20:05
261
原创 想少走弯路，一定要学会第一性原理
把一个复杂问题拆到最基本、最核心、不能再拆的事实，然后从这些事实出发，重新寻找解决办法。它和我们平时的思考方式不太一样。很多人遇到问题，第一反应是：“别人怎么做？” “有没有现成方法？” “有没有成功案例？” “有没有模板可以套？这些问题当然不是不能问。参考别人，可以少走弯路。但如果你永远只问这些，就很容易变成模仿。别人怎么做，你也怎么做；别人买什么，你也买什么；别人走哪条路，你也走哪条路。可是每个人的情况不一样，资源不一样，目标不一样，承受能力也不一样。别人适合的方法，放到你身上，不一定合适。
2026-05-25 08:30:00
369
原创 原型模式：当复制比重新创建更高效时
当已有对象已经足够接近目标对象时，用复制往往比重新创建更自然、更高效。它不是为了让代码显得高级。重复初始化太多对象模板本身有价值变体对象很多复制比重建更符合业务语义某些复杂对象初始化成本较高标准模板需要复用和集中管理原型模式的重点不是“new 一个对象”，而是“从一个现成对象复制出新对象”。参数模板复制仿真场景复制自动化测试工况复制复杂诊断请求模板复制配置对象、任务对象、规则对象的变体生成但它也不适合所有场景。
2026-05-24 23:00:02
383
原创 费曼学习法：普通人最该掌握的高效学习方法
学完一个知识点后，试着把它讲给别人听，而且要讲到一个外行人也能听懂。比如你学了一个概念，不要只在心里说“我懂了”。你可以问问自己：这个东西到底是什么意思？它能解决什么问题？生活里有没有例子？我能不能不用专业词，把它说明白？如果你讲着讲着发现自己卡住了，那就说明这里还没真正懂。这不是坏事，反而是好事。因为你终于发现了自己的知识漏洞。很多时候，我们以为自己懂，是因为书上写得清楚，老师讲得明白，视频讲得生动。但那只是别人懂，不代表你也懂。真正的理解，是你能用自己的话重新讲出来。
2026-05-22 08:30:00
305
原创 建造者模式：复杂对象如何一步步构建
复杂对象不应该靠巨大构造函数或一堆随意 setter 拼出来。它不是为了让代码看起来更花。参数太多导致可读性差可选参数和默认值难管理构建规则散落在调用方对象容易处于半成品状态参数组合是否合法无法集中保证常用构建流程无法复用建造者模式的重点不是“创建对象”，而是“把复杂对象的构建过程表达清楚”。构建复杂诊断报文构建自动化测试工况构建整车配置对象构建仿真场景构建 OTA 升级任务构建数据采集任务参数但它也不适合所有场景。
2026-05-21 22:09:30
454
原创 刻意练习：真正的成长，不是重复努力，而是有方法地变强
刻意练习不是简单地“多练”。它是一种有目标、有反馈、有难度、有调整的训练方式。比如，一个人想提升写作能力。普通练习可能是：每天写一篇文章。写完就发布。发布后继续写下一篇。这种方式当然有价值，至少可以培养习惯。但如果他每次都用同样的结构、同样的表达、同样的问题意识去写，那么写得再多，也可能只是重复原来的水平。刻意练习会不一样。它会先明确一个具体目标：这次只训练开头。这次只训练标题。这次只训练论证结构。这次只训练案例表达。这次只训练结尾升华。然后，它会在练习后进行反馈：开头有没有吸引人？标题是否准确？
2026-05-20 08:30:00
329
原创 抽象工厂模式：一整套对象族如何统一创建？
一整套相关对象，应该由同一套工厂统一创建。它不是为了把创建逻辑写得更复杂。产品族如何统一创建平台差异如何集中管理相关对象如何保证匹配业务代码如何不依赖具体实现测试环境如何整体替换对象族工厂方法关注“创建一个产品”，抽象工厂关注“创建一族产品”。不同车型平台的一整套对象创建不同供应商的一组设备适配真车、仿真、回放环境切换不同协议栈的一套通信对象创建测试环境下的一整套 Mock 对象替换但它也不适合所有场景。
2026-05-19 22:01:47
448
原创 工厂方法模式：为什么对象创建不该到处 new？
对象创建逻辑不应该散落在业务代码里。它不是为了把new包一层。调用方不应该依赖具体类创建逻辑不应该污染业务流程新增实现不应该频繁修改核心代码测试和替换实现应该更容易工厂方法模式的重点不是“帮你创建对象”，而是“把创建变化隔离出去”。不同通信协议对象创建不同供应商驱动创建不同车型控制器创建真车、仿真、测试环境对象切换根据配置创建不同实现但它也不适合所有场景。如果对象类型固定、创建逻辑简单、未来变化很少，就不要为了“看起来像设计模式”而强行抽工厂。
2026-05-18 23:01:27
490
原创 如何减少AI焦虑？
AI回答的质量，很大程度上取决于你提出的问题。如果问题模糊，AI给出的答案也会泛泛而谈。如果问题具体，AI才更可能给出有用的结果。问题越清楚，结果越可控。AI工具迭代很快，这是事实。很多工作会被改变，这也是事实。但这并不意味着每个人都只能被动等待替代。AI时代真正拉开差距的，不只是“谁更早知道一个工具”。而是：谁能更快理解变化。谁能更清楚定义问题。谁能把AI嵌入自己的工作流。谁能持续升级判断力、表达力、学习力和整合能力。谁能把工具变成结果。
2026-05-15 08:30:00
395
原创 聊一聊职场中的软技能
职场中的软技能有很多。沟通能力。协作能力。情绪管理能力。问题解决能力。时间管理能力。学习能力。责任感。适应能力。复盘能力。向上管理能力。边界感。表达与汇报能力。这些能力看起来不像专业技能那样容易量化。但它们会长期影响一个人的工作质量、合作关系和成长速度。专业能力决定一个人能不能完成任务。软技能决定一个人能不能持续获得信任、承担更大责任，并在复杂环境中稳定输出。真正成熟的职场人，不只是把事情做完。
2026-05-13 08:30:00
324
原创 结构化表达：一种被严重低估的底层能力
真正拉开差距的表达能力，不是口才而是信息组织能力。文章指出，表达混乱源于思路不清，本质是缺乏结构化思维。高效表达需要做到：1）结论先行；2）信息分层；3）分类清楚；4）逻辑递进。推荐使用"结论→理由→例证→行动建议"的黄金公式，通过刻意练习框架思维，实现从"说出去"到"传达到"的转变。这种底层能力直接影响个人价值的传递和工作效能的提升，是信息过载时代的核心竞争力。
2026-05-08 08:30:00
312
原创 单例模式：它很方便，但为什么总被骂？
单例模式是一种创建型设计模式，确保一个类只有一个实例并提供全局访问点。它适用于需要严格控制唯一资源的场景，如日志系统、配置中心和全局ID生成器。C++中推荐使用函数内静态局部变量实现线程安全的单例。虽然单例比全局变量多了创建时机控制、实例数量限制和访问逻辑封装等优势，但容易被滥用为"方便访问的全局变量"。在车企项目中，配置中心、日志系统和ID生成器等场景可能适用单例模式。但需注意避免将单例设计成"万能Manager"，否则会导致系统高度耦合、难以维护和测试。单例模式的核心价值在于管理真正的全局唯一资源。
2026-05-06 08:30:00
379
原创 AI时代，如何保持深度思考的能力
AI时代：警惕答案依赖，守护深度思考能力 在AI迅速发展的今天，我们获取答案的效率大幅提升，但同时也面临思考能力退化的风险。本文揭示了AI时代思考能力的七个关键维度：1）区分答案与理解；2）培养追问而非简单提问的能力；3）保留专注思考的时间；4）通过写作整理思维；5）保持理性怀疑态度；6）建立个人知识框架；7）将AI定位为工具而非决策者。文章强调，当AI能快速给出标准答案时，人类更需要培养提出关键问题、建立知识体系、保持独立判断的能力。真正的智慧不在于获取答案的速度，而在于深度思考的质量和独立思考的坚持。
2026-05-01 08:30:00
442
原创 设计模式和 UML 图怎么看
设计模式与UML图的关系本质在于：UML图是压缩表达多个类协作结构的最佳工具，它能直观展现设计模式的核心思想。学习时不应死记硬背模式名称，而应遵循"角色→关系→变化点"的分析路径：先识别抽象接口、具体实现和持有者等角色；再观察继承、组合等关键关系；最后聚焦变化点的组织方式。常见模式骨架包括"抽象+多实现+持有者"、"抽象产品+创建者"、"中心对象+订阅方"等基本结构。绘制UML图时应突出设计意图，重点表现角色分工和关键关系，而非实现细节，这样才能真正理解模式背后的协作逻辑和应对变化的解决方案。
2026-04-29 08:30:00
416
原创 设计模式和 SOLID 到底是什么关系
SOLID 是设计的方向感，> 设计模式是工程里的成熟走法；> 真正会设计的人，不是只会背原则，也不是只会背模式，> 而是能用原则看清问题，再用模式组织结构。
2026-04-27 08:30:00
379
原创 不靠意志力的自律方案
这篇文章探讨了如何建立可持续的自律系统，而非依赖意志力硬撑。作者提出8个关键方法：1）用"如何更容易做到"替代"必须做到"；2）降低行动启动门槛；3）优化环境减少内耗；4）固定行为触发点；5）接受"低配完成"保持连续性；6）建立即时反馈机制；7）允许失误但避免连续中断；8）用自我协作替代自我攻击。核心观点是：真正的自律不是自我对抗，而是通过系统设计让正确行为自然发生，减少对意志力的依赖，实现温和而持久的改变。
2026-04-24 08:30:00
385
原创 内存管理全景指南
本文系统介绍了从硬件到应用层的内存管理原理与实践。内容涵盖硬件层（物理内存结构、缓存层次、MMU地址转换）、操作系统层（进程地址空间、虚拟内存管理）、语言层（C/C++内存管理）以及应用层的最佳实践。特别针对车企场景，分析了嵌入式系统和实时操作系统中的特殊内存管理需求，如传感器数据处理优化、AUTOSAR安全分区等。通过分层视图和实际案例，帮助读者全面理解内存管理对系统性能、稳定性和安全性的关键影响，并掌握不同场景下的优化方法。
2026-04-20 08:30:00
754
原创 初入职场：用复盘，让每一次“踩坑”都成为成长的阶梯
职场新人快速成长的秘诀：5步复盘法 摘要：职场新人常因缺乏经验而犯错，复盘是快速成长的有效方法。本文提出5步复盘法：1）回顾事实，明确目标与差距；2）对比分析，找出关键问题；3）深挖原因，用5Why分析法；4）提炼经验教训；5）制定改进计划。通过系统性复盘，新人能将每次失误转化为成长机会，避免重复犯错。文章还列举了常见误区（如将复盘等同于自我否定）和实用技巧（及时复盘、聚焦单点等）。坚持复盘能让职场新人快速积累经验，提升工作能力。
2026-04-17 08:30:00
222
原创 C++ 模板编程指南
本文系统介绍了C++模板编程的核心概念与应用。主要内容包括： 模板概述：解释了模板作为泛型编程基础的作用，对比了模板与宏、继承的差异 函数模板：详细讲解语法、多类型参数、非类型参数及实例化原理，并给出传感器滤波等实例 类模板：介绍基本语法和应用场景 其他模板特性：变量模板、别名模板等高级用法 模板特化与元编程基础 车企应用案例展示模板在实际开发中的价值 全文通过代码示例和图示，系统阐述了模板编程的技术要点，为开发高效、类型安全的通用代码提供了实践指导。
2026-04-15 08:30:00
361
原创 为什么需要设计模式，而不是只会写类
设计模式不是抽象概念，而是应对复杂性的工程经验。当系统从"能跑"走向长期维护时，仅会写类已不够。设计模式解决的是：如何组织类协作，使系统在变化中保持稳定。它帮助控制变化影响面、规范复杂协作、提升长期可维护性。模式不是高级语法或代码模板，而是可复用的设计思路。在车企等复杂业务场景中，随着状态、协议、平台差异增多，模式会自然浮现。掌握模式的核心是识别问题本质，而非机械套用。当业务复杂度达到临界点，合理运用模式能有效控制代码膨胀，使系统更易于演进和维护。
2026-04-13 08:30:00
409
原创 C++ 类关系指南
摘要：本文系统梳理了C++中的类关系类型，包括继承、实现、依赖、关联、聚合和组合等，通过汽车行业实例与UML图示说明其应用。文章首先强调理解类关系的重要性，特别是在汽车软件等复杂系统中。随后详细解析每种关系的定义、特点、适用场景及C++实现方式，并给出UML表示方法。最后通过对比表帮助区分易混淆关系，为工程实践中的类关系选择提供指导。
2026-04-10 08:30:00
421
原创 类的封装与定义指南
本文探讨了如何定义工程上真正可用的类，强调除SOLID原则外，还需考虑状态管理、边界控制等实际因素。文章首先解析SOLID五大原则（单一职责、开闭原则等）的核心原理与典型应用场景，指出其本质是通过控制依赖方向来限制变化影响范围。随后指出SOLID的局限性，提出类设计还需关注线程安全、性能等工程要素，并给出车企场景下的电机控制、诊断服务等实例说明。最后提供实用检查清单，强调好的类设计应同时满足理论原则和工程实践需求，在抽象与实现间取得平衡。
2026-04-08 08:30:00
363
原创 防御性编程技巧与实践
本文系统介绍了防御性编程在车企嵌入式软件开发中的应用。防御性编程的核心思想是主动预防和处理潜在错误，在车载系统中尤为重要。文章重点阐述了输入验证和边界保护两大关键实践：输入验证强调对所有外部数据进行有效性检查，包括指针、范围、状态等；边界保护则通过数组边界检查、缓冲区溢出防护等技术确保内存安全。文中提供了大量C语言代码示例，展示了如何通过参数校验宏、安全数组访问等技术实现防御性编程。这些实践可显著提升车载软件的可靠性和安全性。
2026-04-06 08:30:00
789
软件设计文档模板.rar
2021-09-22
空空如也
TA创建的收藏夹 TA关注的收藏夹
TA关注的人