所谓解耦
Created|Updated
|Word Count:159|Reading Time:1mins|Post Views:
软件设计,必有单元/片段,不管他们叫做系统、层次、模块、类型和方法,都是为了在一个抽象颗粒度上分割复杂度,让我们降低思考的难度,并且进行团队协作。
我们在进行系统交互的时候,要尽量设计单元交叉点通过薄的中间层交互。也就是放弃直接性,拥抱间接性。
间接性的实现,就是契约、接口或者门面/桥接模式。这些实践的使用,可以轻易让我们切换层次之间的实现,而使变动不扩散出去。
Author: magicliang
Copyright Notice: All articles on this blog are licensed under CC BY-NC-SA 4.0 unless otherwise stated.
Related Articles

2026-03-27
驾驭工程全景:从 Prompt Engineering 到 Context Engineering 再到 Harness Engineering 的三级跃迁
2020 年我们学会了跟模型说话(Prompt Engineering),2025 年我们学会了给模型喂信息(Context Engineering),2026 年我们学会了给模型搭脚手架(Harness Engineering)。这三个 Engineering 不是并列关系,而是严格的超集关系:PE ⊂ CE ⊂ HE。本文从"为什么上一个不够"的视角,系统梳理这条演进路径上的每一次范式跃迁。 一个类比秒懂三级跃迁 在讲技术之前,先用一个所有人都能理解的类比。 想象你要指挥一个完全失忆的天才厨师做一桌满汉全席: Prompt Engineering 就是学会怎么跟厨师下达指令。你发现说"做道好吃的"不行,得说"用中火煎三分钟,翻面后加酱油 15 毫升"。这是措辞的艺术。 Context Engineering 就是学会怎么给厨师备料。光会下指令不够——厨师面前得摆好食材、调料、菜谱、食客的过敏信息。你要设计一个动态备料系统,让厨师在需要的时候拿到需要的东西。 Harness Engineering 就是学会怎么...

2026-02-07
API 兼容性设计
在软件工程中,API 兼容性是一个至关重要但又经常被忽视的问题。良好的兼容性设计能够确保系统的平滑演进,避免因 API 变更导致的客户端崩溃和服务中断。本文将从多个维度探讨 API 兼容性设计的最佳实践。 什么是 API 兼容性 API 兼容性分为两种类型: 向前兼容:旧版本的客户端能够与新版本的服务端正常通信。即服务端升级后,旧客户端仍能正常工作。 向后兼容:新版本的客户端能够与旧版本的服务端正常通信。即客户端升级后,旧服务端仍能提供服务。 在实际项目中,我们通常更关注向前兼容,因为服务端的升级往往不可控,而客户端的更新节奏各异。 破坏性变更的分类 破坏性变更是指会导致现有客户端无法正常工作的 API 变更。主要分为三类: 1. 接口签名变更 123456789// 变更前public interface UserService { User getUser(String userId);}// 变更后 - 破坏性变更public interface UserService { User getUser(String userId,...

2024-09-25
飞马模型
飞马模型来自 IBM 的 FSDM 模型 飞马模型可以覆盖银行、证券和保险业务场景,更加容易实现“全局最优”的金融信息互通、集成标准的建立。 飞马模型包括9类主题:产品、合约、条件、参与者、账户、事件、渠道、资源项、位置 。与FSDM的9大概念( 参与者、合约、条件、产品、地点/位置、分类、业务方向、事件、资源项)相比,飞马模型少了分类和业务方向,增加了账户和渠道两个主题,更加贴合金融业务特点。 账户的概念来源于会计核算中的会计账户。银行账户是客户在银行开立的存款账户、贷款账户、往来账户的总称。银行业务就是在账户体系基础上为个人和对公客户提供各种金融服务。账户体系定义所有的操作均以交易的形式发生,也就是信息模型中的事件。 渠道是银行为客户提供金融产品和服务的场所。渠道的作用在于触达客户、传递产品和服务、达成交易。对于传统金融机构,同时拥有线下渠道和线上渠道。而对于互联网金融来说,完全是线上渠道。这也决定了互联网金融的业务模式与传统金融机构相比存在较大的差异,渠道对于互联网金融来说意义更大。互联网渠道不仅能够完成触达客户、传递产品和服务、达成交易的基本作用,而且其所带来的全新优质...

2019-12-31
代码大全
第 1 章 欢迎进入软件构建的世界 第 2 章 用隐喻来更充分地理解软件开发 第 3 章 三思而后行:前期准备 第 4 章 关键的“构建决策” 第 5 章 软件构建中的设计 第 6 章 可以工作的类 第 7 章 高质量的子程序 第 8 章 防御式编程 第 9 章 伪代码编程过程 第 10 章 使用变量的一般事项 第 11 章 变量名的力量 第 12 章 基本数据类型 第 13 章 不常见的数据类型 第 14 章 组织直线型代码 第 15 章 使用条件语句 第 16 章 控制循环 第 17 章 不常见的控制结构 第 18 章 表驱动法 第 19 章 一般控制问题 第 20 章 软件质量概述 第 21 章 协同构建 第 22 章 开发者测试 第 23 章 调试 第 24 章 重构 第 25 章 代码调整策略 第 26 章 代码调整技术 第 27 章 程序规模对构建的影响 第 28 章 管理构建 第 29 章 集成 第 30 章 编程工具 第 31 章 布局与风格 第 32 章 自说明代码 第 33 章 个人性格 第 34 章 软件工艺的话题 第 35 章 何处有更多的信息

2018-10-26
checklist
写代码 checklist 注意位置 注意顺序 注意初始化 注意返回值 注意注释 注意防御性编程 注意数据库性能 上线 checklist 代码变更 check 代码 配置变更 check 配置 系统变更注意上线顺序 依赖中间件变更注意配置中间件 配置中心配了吗 交互所有细节都实现了吗? 配监控和埋点 数据库变更了吗? 安全检查

2018-03-07
语义版本化问题
语义化版本 2.0.0 《语义化版本 2.0.0》,三段版本号语义: 版本格式:主版本号.次版本号.修订号(MAJOR.MINOR.PATCH),版本号递增规则如下: 主版本号(MAJOR):当你做了不兼容的 API 修改, 次版本号(MINOR):当你做了向下兼容的功能性新增, 修订号(PATCH):当你做了向下兼容的问题修正。 先行版本号及版本编译信息可以加到"主版本号.次版本号.修订号"的后面,作为延伸。例如 1.0.0-alpha、1.0.0-beta.1、1.0.0-0.3.7。 版本号的初始阶段 在主版本号为 0.x.y 的阶段,API 被认为是不稳定的,任何变更都可能发生。这个阶段的软件不应该被用于生产环境。1.0.0 的发布意味着公共 API 的正式定义,后续的版本号变更都基于这个公共 API 的变化来递增。 先行版本号(Pre-release) 先行版本号通过在修订号后面加上连字符和一系列以点分隔的标识符来表示。例如: 1.0.0-alpha < 1.0.0-alpha.1 < 1.0.0-beta < 1.0.0-b...
Announcement
人生只是,守株待兔




