Interface（Java关键字）天然是接…

      看到这个题目，会不会觉得我精神错乱了？Interface不就是英文的接口吗？先说明下本文所有的“Interface”指的是Java的关键字interface所代表的概念：对于C++来说就是只包含纯虚函数的抽象类。
      最近在Java Eyes看了篇挺好的文章：《关于Java开发不明白的一些问题》。里面包含了对Java一些领域过度包装，过于奇技淫巧的“主流”做法的思考。这不禁让我想起C++狂吹泛型编程概念，代码飞到月亮之上的岁月。还好现在C++已经返璞归真了——估计“专家”觉得c++太冷清于是跑去Java开party了。
      我读研时大部分代码是用Java写的（没做BS，都是些应用程序，还有几个多线程TCP服务器之类的）。直到现在我都认为Java程序员比C++幸福多了（为啥毕业后倒跑去做C了？咳咳咳咳，在厦门不会做网页的Java程序员没有用武之地）——不用整天为了点小事满地找类库，出错定位很容易（在合适的地方捕获异常printStackTrace vs 0xXXXXXXXX内存不能写，应用程序非法退出）。所以我当时对Java的评价是重剑无锋大巧不工。
      但最近我需要与一个Java写的TCP服务器通信，通信协议使用Google Protobuf来做正反序列化。听起来不难？我也是这么觉得的。可是一看协议，我哭了：协议头里面居然没有包长度！怎么可能没有包长度？那接收端怎么知道要接收多少数据，是否接收完成？问Java开发者。他们很惊讶。为啥要发包长度，TCP不能“自动”知道吗？（不奇怪，Javer一般很少做TCP服务器）不过他们提供了一个信息，Java服务端使用了netty框架（Java的NIO已经够简单了，为啥还要引入框架？比起netty，naked不是更好吗）。好吧。既然是开源的，有源码有真相，让我们看它做了啥……，……，……，……，……，……，……，……会不会觉得我的省略号太多了？比它的跳转好多了！一个个的接口，一个个的类，跳来跳去的，往往实现类中的函数就一个调用——又跳到另一个接口去了。满地找牙，虎目含泪，我不记得到底跳转了几次，终于看到一条救命的信息——从某个接口函数的入参说明中大抵猜测出框架在包前加了一个4字节的包长度字段——还不知道是little-endian还是big-endian，但我实在没勇气再找下去了，跳转太剧烈了我已经晕了，大头小头直接抓包看吧。
      面向接口编程增强了扩展性和可读性？我不反对，但前提是-正确使用他们。该拳拳到肉的时候就别整日耍花枪。来段万金油的说法：该耦合不耦合是过度设计；不该耦合耦合是过度不设计；正确做法是该耦合时耦合，不该耦合时不耦合。这段话指导意义不大：因为何时是该耦合？何时是不该耦合？这才是大家争论最大的地方。
      不同模块？不同层次就一定要通过Interface（Java关键字）来调用吗？？我觉得这是错误的。这也是导致netty框架找个干活的代码块无比困难的原因。我曾经看过一个Java程序，他把所有类都提出一个interface，基本每个interface都只有一个实现类。这就是典型的Interface控。我不觉得这种做法除了折腾自己有任何意义？可扩展？修改一个地方方便还是两个地方方便？可读？通过接口找实现是很麻烦的事情。
      在我看来，抽取Interface要么是有两个以上实现或者非常Sure会有不止一个实现，要么多态带来的利益大于它的代价。是的，多态能干掉随地乱摆容易出错的if-else。但是如果if-else不多，抽Interface未必就优越于通过参数来设置。任何设计都是一个权衡的过程。抽Interface不是毫无副作用的万能做法，他会额外增加复杂度和工作量。所有面向对象的设计模式都是有代价的。不管3721就开始抽Interface，口里喊着面向接口，其实不过是放弃主动思考的借口罢了。
      我认为从调用到真正做事经过太多次跳转也是代码坏味道的一种（而这个弥漫在很多Java程序中）。因为它一样带来理解和维护的极大困难。
      模块间面向接口编程毫无疑问是正确的。否则组内和组间协作将是一场噩梦。但接口不止是Interface，类的public函数，甚至一组声明在头文件里的函数（c/c++)，也是接口的一种。而且他们在过去表现良好。Interface天然是接口，但接口远不止是Interface。