??在web開發(fā)的工作，mvc也是比較常用的開發(fā)模式，這種開發(fā)模式通常將代碼分成三層(控制層、業(yè)務(wù)邏輯層、數(shù)據(jù)庫訪問層)，無論是較早的SSH、SSM、還是現(xiàn)在比較流行的spring boot框架，都提倡面向接口編程，這樣可以降低層與層之間的耦合。這已經(jīng)成為了一種范式，大家都去遵守，寫著寫著就有點像八股文。在利用面向?qū)ο蟮恼Z言進行大型系統(tǒng)的設(shè)計需要考慮各個對象之間的交互的問題，接口本質(zhì)是一種規(guī)范和約束，反映了系統(tǒng)設(shè)計者對系統(tǒng)的抽象理解。換一種說法，面向接口編程，寫業(yè)務(wù)的不需要遵守。當(dāng)設(shè)計和實現(xiàn)分離的時候，面向接口編程是一種解決問題的很好方式，但是當(dāng)設(shè)計和分離是一個人的時候，就顯得非常沒有必要。下面分別討論這兩種情況：
1）框架設(shè)計
??這種情況下，設(shè)計和實現(xiàn)是分離的。面向接口的設(shè)計，能保證框架的擴展性。比如設(shè)計物流運輸系統(tǒng)，針對運輸這個過程，系統(tǒng)設(shè)計人員經(jīng)過抽象，將物流公司的運輸行為分解為三個過程:接單、送達(dá)，結(jié)算，用戶評價，那么可以定義一個接口約束這種行為：
public interface Transport {
//接單
void receiveOrder();
//運達(dá)
void arrive();
//結(jié)算
void pay();
//用戶反饋
void userComment();
}
業(yè)務(wù)系統(tǒng)中有各種配送方式，比如外包(A運輸公司、B運輸公司等)、自己配送，直接實現(xiàn)上面的接口，然后在里面寫具體的業(yè)務(wù)實現(xiàn)。然后將這種實現(xiàn)交由spring管理，框架在執(zhí)行業(yè)務(wù)的時候，根據(jù)參數(shù)從spring中取出相應(yīng)的實現(xiàn)，然后執(zhí)行相應(yīng)的業(yè)務(wù)邏輯。
public class TransportExecutor {
public void transport(int selectedType){
if(selectedType==1){
//外包
//模擬隨機分配訂單到運輸公司
int flag=new Random().nextInt(10);
//根據(jù)flag讀取配置,取出component的name
String companyName= PropertyUtil.getCompanyByFlag(flag);
Transport transport=SpringBeanUtil.getBeanByName("name");
transport.receiveOrder();
transport.arrive();
transport.pay();
transport.userComment();
}else{
//自己運輸
}
}
}
??另外面向接口編程在mybatis中應(yīng)用也比較普遍，mybatis中的mapper的接口其實就是一個標(biāo)記，mybatis為每個接口都生成了一個動態(tài)代理對象，業(yè)務(wù)層中或者dao層調(diào)用mapper接口中的方法時，其實是調(diào)用生成的動態(tài)代理對象，在代理對象相應(yīng)的方法中完成sql語句的執(zhí)行。
sqlsession.getMapper(class)
-->
public <T> T getMapper(Class<T> type) {
return configuration.<T>getMapper(type, this);
}
-->
@SuppressWarnings("unchecked")
public <T> T getMapper(Class<T> type, SqlSession sqlSession) {
//knownMappers.get(type) 獲取代理工廠，knowMapper加載配置文件的時候初始化，為每個mapper接口創(chuàng)建一個代理工廠
final MapperProxyFactory<T> mapperProxyFactory = (MapperProxyFactory<T>) knownMappers.get(type);
if (mapperProxyFactory == null) {
throw new BindingException("Type " + type + " is not known to the MapperRegistry.");
}
try {
//通過代理工廠，生產(chǎn)一個mapper的實例，里面的invoke方法封裝了具體的信息，見下面分析
return mapperProxyFactory.newInstance(sqlSession);
} catch (Exception e) {
throw new BindingException("Error getting mapper instance. Cause: " + e, e);
}
}
--->
public T newInstance(SqlSession sqlSession) {
final MapperProxy<T> mapperProxy = new MapperProxy<T>(sqlSession, mapperInterface, methodCache);
return newInstance(mapperProxy);
}
--->
@SuppressWarnings("unchecked")
protected T newInstance(MapperProxy<T> mapperProxy) {
//mapperProxy實現(xiàn)了InvocationHandler方法
return (T) Proxy.newProxyInstance(mapperInterface.getClassLoader(), new Class[] { mapperInterface }, mapperProxy);
}
---> mapperProxy中invoke方法
@Override
public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
try {
//判斷接口是否有實現(xiàn)類，若沒有執(zhí)行下面邏輯 此處不能有，不然后續(xù)無法執(zhí)行sql
if (Object.class.equals(method.getDeclaringClass())) {
return method.invoke(this, args);
} else if (isDefaultMethod(method)) {
return invokeDefaultMethod(proxy, method, args);
}
} catch (Throwable t) {
throw ExceptionUtil.unwrapThrowable(t);
}
2）業(yè)務(wù)開發(fā)
??面對很簡單的業(yè)務(wù)模型（crud），在應(yīng)用內(nèi)各層(controller、service、dao)之間相互調(diào)用，不存在定義和實現(xiàn)分離的情況，這個時候就沒必要再面向接口編程。這樣可以減少沒有必要的工作量。大家統(tǒng)一約束好（業(yè)務(wù)層類命名直接以service結(jié)尾，不用接口和實現(xiàn)分離），需要調(diào)用其他人寫的業(yè)務(wù)方法，直接注入實現(xiàn)即可，其他人修改實現(xiàn)，不會影響你的調(diào)用。
@Service
public class TransportService {
@Autowired
//此處直接注入實現(xiàn)類
private UserLoginService userLoginService;
public void transport(int selectedType){
userLoginService.checkLoin();//調(diào)用實現(xiàn)類中的方法
}
}
