扯扯Java开发的淡

  有人说：这个世界上有两件最难的事， 一是把别人的钱装进自己的口袋；二是把自己的思想装进别人的脑袋。对于第一件，有些人做起来并没有那么难，而且做得相当成功，那就是乞丐；至于第二件有两类人做得比较成功，但却艰辛地多，其中一类是老师，另一类则是创业者。

  我不是老师，也不是创业者，但我想做做第二件事。

  作为一个从事 Java 后端开发的程序员，自然避免不了要为前端编写后台接口。那么，应该给前端编写几个后端接口呢？这个问题的答案就是我想传达的思想。

  在回答这个问题之前，我们不妨思考一下另一个问题：要处理这个世界上所有的业务需求，至少需要几个后端接口？

  我的答案是：一个。

  诸位，先不要抛砖，以免砸到了玉。

  要把这个世界上所有的业务都讲清楚，靠这一篇文章自然是不可能。不妨将其浓缩一下：假如此时此刻，我们每个人都是游戏里的一个人物，业务场景是控制游戏里每个人每天的生活。

  现在我们尝试用一个接口去处理这个业务，看看是否行得通。

  人的生活无非是吃穿住行，那么这个接口就需要一个参数去知道一个人是要吃、要穿、要住还是要行。假如这个人是要吃，那么我们还需要知道这个人要吃什么，那就需要另外一个参数。同样地什么时候吃，吃多少、是否需要付钱、付多少钱等等这些都可以通过增加接口的入参来控制。

  有人会说，除了吃穿住行，人还有其他更多的事可以做，但与此同时这个接口也可以有更多的参数可以加，不是吗？总之使用一个接口是可以处理控制一个人一天的生活这个业务需求的，进而这一个接口也可以处理这个世界上所有的业务需求，对吗？

  可以不意味着可行，我们当然不可能使用一个接口去处理所有的业务，因为这对于前后端的交互是灾难性的，其前端传参和后端参数处理的复杂程度是不人性、也不人道的。

  回到正题：后台应该为前端编写几个接口？注意这里的措辞，是“编写”而非“提供”。

  我的初步答案是：四个，即增删改查。

  我想做过软件开发的人听到的最多的大概就是这四个字了，所谓耳熟能详，但此时此刻，我想你正在曲解我的意思。因为我所说的四个并非是四类，而是数量上的 4 个——即对于每个系统来说，后端只需要编写 4 个接口。

  以上是引言，接下来是我的论证。

  对于任何一个有前后端交互的系统而言，其交互地本质无非是通过前端传参通知后端应该对哪些数据进行增删改查操作。比如对于一个电商平台系统而言，可能会涉及到对商品的增删改查操作、对店铺的增删改查操作、对交易的增删改查操作等。假如一个电商平台只有上面列举出来的三类业务场景，那么作为后台需要为前端提供的接口数量至少应该是 3 个增删改查，也就是需要提供 3 * 4 = 12 个接口，注意这里的措辞，是“提供”而非“编写”。

  这 12 个接口中有 3 个增 、 3 个删、 3 个改、3 个查，而所有的增加操作都是类似的，同样所有的删改查操作也都是类似的。我们都知道，在 Java 中有类的继承的概念，倘若我们在父类中实现了增、删、改、查操作，然后让子类去继承，那就意味着所有的增加操作只需要编写一遍，同样地，所有的删改查操作也只需要编写一遍，也就是说我们只需要在父类中编写一次增删改查，对吗？这样的话，就印证了我所说的只需要为前端编写 4 个接口。

  可是，有一个问题：在父类中实现增删改查，那么父类怎么知道具体应该增删改查哪一类对象呢？就上面的举例而言，父类怎么知道是要对商品进行增删改查，还是对店铺进行增删改查，还是对交易进行增删改查呢？

  答案是：通过泛型。

  Java 中有泛型的概念，子类在继承父类的时候可以指明泛型类，通过带泛型的继承就可以让父类知道具体应该操作哪一类对象。说到泛型，我想说一下自己的理解：在 Java 中“一切皆对象”——即一切事物都可以被抽象为一个对象，而泛型则是对所有抽象的抽象。换言之，泛型是介于抽象的具体对象和 Java 中 Object 对象之间的一种对象形态，因为它是对具体对象的抽象，也是对抽象对象的具体。

  至此，对于单表的增删改查操作基本上就解决了。但这还远不够，因为任何一个系统都会涉及到联表操作，比如在增加操作中可能会有多对多关系的创建、在查询操作中可能会有多对多关系的数据回显等。这些问题可以在编写的这 4 个接口中解决吗？

  答案是：可以。

  怎么解决呢？通过注解和反射。我们可以自定义注解，在自定义的注解中去指明一个属性应该和哪一个类建立关联关系以及建立的关联关系是哪一个类，然后通过反射来获取双方的主键，最后映射至关联关系表中。在查询的时候再通过这个注解去解析应该关联哪个表以进行数据的回显。我想通篇看下来，大概只有这个地方理解起来有些晦涩，如果你有这种感觉的话，不妨看一下我的另一篇系列博客：基于Java的泛型和反射实现通用的增删改查，这个系列博客中不仅仅有对于通用的增删改查的实现，还包含通用的导入、导出、按字段统计等，目前这个系列博客也还在完善之中。

  以上，是对于我“初步的答案”做出的论证。当然“初步的答案”并非正确的答案，因为前后端的交互可能还会涉及到上传、下载、导入、导出等，这些操作理论上说也都是可以抽取到父类中的。如此一来，后台需要为前端编写的接口数量就会变为一个常数，至于这个常数的值则需要看前后端交互有多少种场景。

  以上是我对于 Java 后台开发的一点感悟，如有失偏颇，还望海涵，若有班门弄斧之嫌，敬请留言指正。