后端三层架构，其中接口是否被滥用了？

发现无论是.net还是java，在传统的web应用中，接口完全没有意义，举以下的例子 转账的接口

public interface TransMoney(){
          
   
	bool transMoney(String id,int money);
}

这里是实现类

public class TransMoneyImp implements  TransMoney{
          
   
	@Override
	public bool transMoney(String id,int money){
          
   
		//具体实现
	}
}

传统的web应用中，以上的具体实现都是基于固定某个数据库进行操作的，不存在说有多种数据库都要实现同样的转账逻辑

实际上，接口真正发挥作用的是在接入多种品牌的统一种设备时，多个开发人员已统一的参数接入多种品牌的统一种设备时，例如3个开发人员，分别接入不同的厂商的设备时，实现同一个接口，保证调用参数的一致性。

public interface Inter(){
          
   
	bool handle(String p1,String p2);
}

这里是实现类

public class InterImp1 implements  Inter{
          
   
	@Override
	public bool handle(String p1,String p2){
          
   
		//具体实现1
	}
}

public class InterImp2 implements  Inter{
          
   
	@Override
	public bool handle(String p1,String p2){
          
   
		//具体实现2
	}
}

public class InterImp3 implements  Inter{
          
   
	@Override
	public bool handle(String p1,String p2){
          
   
		//具体实现3
	}
}

既然一般的业务都是对单独数据库单独表操作，可以理解为，这种逻辑操作都是唯一的，例如一开始的转账，同一个数据库同一个逻辑方法，对接口只会存在一种实现，而且可以发现一般的web项目中对接口的实现90%以上都是只有一种实现的。像对接多个设备之类的较少，一般的curd都是对接口仅有唯一实现。 那为何还要存在这么多的接口呢？为何不能直接提供实现呢？ 感觉归根结底还是框架的滥用，导致的， 很多开发者甚至也不清楚为何要先定义接口再去写实现，反正框架就这样，或者IDE提供的代码生成如此。

然后是有人提出的，对接口的唯一实现要修改，如果有接口，可以新增一个实现而不是修改原来的实现，显然，如果原来的实现是错误的，或者有bug的，那么完全可以直接修改而并不需要通过接口的多种实现来做到。

此外，所谓接口的易于扩展，完全是在接口本身设计就能够满足后续的扩展需求的前提下的 例如在接入多种品牌的统一种设备时 接口定义的方法只有参数p1和p2

public interface Inter(){
          
   
	bool handle(String p1,String p2);
}

但是，后续需要扩展一种新的厂家的设备，需要三个参数， 这个时候显然无法用以上的接口进行扩展，只能另起炉灶了。

又或者最常见的情况下，多个开发人员人员更替，前辈的代码，后辈总是不高兴去继承的，遇到在接入多种品牌的统一种设备时，新增了一种设备，后来者也大多会去自定义接口去实现，毕竟如果复用之前的接口还要考虑是否满足这次扩展。。。。