一、接口的每个出参只能对应一个意思
例子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一定非常多。
所以在接口设计上，一定要让每个出参在逻辑上互不干涉。
