持续创作，加速成长！这是我参与「掘金日新计划 · 6 月更文挑战」的第24天，点击查看活动详情
背景
-
一线公司都实现了前后端分离的开发模式。除去所谓的Restful接口设计模式，如何来设计接口呢？
-
基本信息：项目有中文版和英文版，也有稳定区和创新区，这里的稳定区和创新区只是一个业务逻辑上的一个概念。
-
需求：我们需要查询项目，而条件是中文还是英文，稳定区还是创新区。
-
这里主要分析是通过接口类别来隔离业务逻辑，还是通过一个接口的参数不同来区分业务类别呢？
过程
思路一：后台接口设计，采用完全隔离的方式。 1， 稳定区的中文项目一个接口。 2， 稳定区的英文项目一个接口。 3， 创新区的中文项目一个接口。 4， 创新区的英文项目一个接口。
优点：如果把具体的接口设计，当成一个类的话，引起类变化的原因就一个都没有了。而且在理解起来，非常简单。真正意义上做到了完全隔离。
缺点：代码会有重复逻辑结构。并且接口太多，繁琐。
其实，很多开发者，会问为什么不抽象一下呢？
思路二：后台接口设计，采用只有一个原因引起类的变化。 1， 稳定区项目一个接口，需要参数分类是中文或者英文。 2， 创新区项目一个接口，需要参数分类是中文或者英文。
优点：如果把接口设计理解成一个类的话，引起类变化的原因就只有一个。好理解，简单。控制逻辑需要写一个判断，业务逻辑也需要一个判断。这里判断的原因就是不同的逻辑有不同的具体实现过程。
缺点：如果还有新项目添加的情况，会修改原来的代码，至少会添加一个判断。这样就违背开闭设计原则。不仅，有新类型项目添加，也有可能有新语言类型添加，这样需要在原来的逻辑上进行修改。
继续抽象。
思路三：后台接口设计，采用有两个原因引起类的变化。（项目类型和中英文版本） 一个接口，需要参数中文还是英文，稳定还是创新。
优点：接口从4个减少到1个了。
缺点：一个业务逻辑中，有很多控制逻辑，如果不小心把控制逻辑结构和业务逻辑结构混杂在一起了，当接口出现bug,我们在调试程序的时候，需要判断当前参数是稳定项目还是创新项目是中文还是英文。至少需要跟前端同事进行一系列沟通，而沟通是一件很浪费时间的事情。当然，我们可以小心地把判断逻辑隔离出来，抽象成一个小小的功能函数，把业务逻辑给抽离出来。这样在排查问题的时候，会好很多。但是，跟前台沟通的成本是减少不了。
思考：
-
无论是哪种实现方式，都应该把控制逻辑小心地抽离出来，把功能逻辑抽离出来。
-
是思路一好呢，还是思路二好呢？如果从类的角度来思考的话，思路二比较好，只有一个参变量。也就是不能没有参数类型。但也不能像思路三那样参数太多。因为参数太多了，沟通成本高，写代码需要更加小心抽离控制逻辑和业务逻辑。
-
最核心的还是，考虑到当前问题是否可以耦合在一起？ a) 今天是中文和英文两个语言，可是明天有可能添加法语呢？这个时候，我们最好还是扩展原来的逻辑而不是在原来的代码上进行修改。
b) 今天是稳定项目和创新项目，可是明天有可能添加希望项目呢？这个时候，我们难道去修改原来的逻辑吗？在控制逻辑中多加一个判断，在业务逻辑中多添加一个判断。
c) 可能开发经验不足的，会理想上或者相当然，每一类的业务逻辑是一样的，确实它的逻辑过程一定是一样的。但是，每一个类别的表结构是不一样的，也根本无法抽象起来，成为一个通用逻辑代码块。
d) 其实，我们可能对代码复用有一些误解。真正的代码复用是一些基础代码，比如日志的记录代码，比如附件的逻辑代码，比如接口的入参的解密，出参的加密过程，这些代码一定是需要复用的。而对于一个业务逻辑来说，我们真的可以十分肯定它内部的类别，每个类别都是一模一样的吗？表结构是一样的吗？字段名称是一样的吗？很难保证，因为既然是类别了，它一定是有一些自己独特的性质的，不然干嘛分类，他们就是一类的呀。
小结
-
不要像思考三设计，杂糅成一个接口了，这样需要小心抽离控制逻辑和业务逻辑。
-
也不要选择思路二，单一的类别方式。这样的方式依然无法满足开闭原则，既然无法满足开闭原则，则添加新的类别后，很大可能引入新的bug。还有一种情况，如果其中一个类别有bug了，所有逻辑都跑不起来了。这就是耦合代码，也是所谓的代码复用带来的弊端。
-
选择思路一。如果把接口设计想象成一个类，那么无论是扩展语言类型还是项目类型，都不会修改原来的逻辑，而是根据模板代码，如果有新的类别加入，则重新添加一套逻辑代码即可。思路一接口多，繁琐。但是在前台有不同的tab页进行分类，也不用写逻辑判断。所以还是大胆选择思路一吧。
