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