一、接口的每个出参只能对应一个意思 例子1.服务端返回一个的时间戳(countDownNum),APP用它来进行的业务处理,每过一秒,时间戳的值减1,终时间戳会被减小到0,当时间戳减小到0时,展示界面A。 程序员A说:当countDownNum > 0 时,开始,隐藏页面A,当countDownNu <= 0时,结束倒计,展示界面A。 分析一下,这样一个逻辑 中countDownNum承担了3种意思:1.是否展示页面A ;2.展示的总数额,3.是否开始。 有,产品的需求变更了,要求APP在情况1时,展示界面A并开始, 在情况2时,隐藏界面A并开始,在情况3时,显示页面A,不开始,但显示总数额。 如果按照程序员A所说的做法,需要改代码了,因为无论是情况1还是2,countDownNum都是大于0的。这时,服务端再多加2个出参, 用于页面A是否展示(isShowA),用于是否开始(isCountDownStart) 设想一下,如果我们从一开始将3种意思分别拆分出来用3个出参去表达,是不是能应对产品的需求变更了呢? 二、接口的每个出参不能存在互斥的逻辑污染 例子1,服务端返回给APP两个出参,一个负责页面是否展示(isShow),另一个负责页面展示的文本(text)。 程序员A说:如果text为空,不展示页面,如果不为空,展示页面,并且在页面上显示text的值。 这种思想首先犯了一中提到的错误,让text表达了2个意思,其次因为text把isShow的逻辑剥夺了, 让isShow在逻辑表达上失去效用,或者说存在逻辑互斥污染,改变了接口原有的意思, 破坏了接口逻辑的控制。 出参的每个属性都应该垂直表达到APP端,并且和其他出参在逻辑上保持平行,不能存在任何的交叉线。 举个出参逻辑污染的极端例子,服务端给APP的有A1~A100个出参,都是boolean型,其中A1为true时 A2的值无效,A3为true时A4的值要取反......一直到A100,可以想象这样的设计出来的软件, bug一定非常多。 所以在接口设计上,一定要让每个出参在逻辑上互不干涉。