IOC，把控制反轉到業務端，這句話沒什么問題，在springboot框架里，對象的管理是通過spring ioc來實現的，而開發人員的開發原則里總是說“面向接口編程”，而為什么要面向接口卻沒幾個人能說出來，今天在寫一個基於redis的手動分布鎖時，對這個面向接口和控制反轉又有了一個體會。
底層代碼更需要面向接口
當你為開發人員提供一個封閉的包時，他們是直接用的，他們不會修改你的代碼，當然他們可以去繼承並擴展；當然如果你不希望被繼承可以聲明為final，這都是面向對象編程里提供好的功能，我們主要看控制反轉這句話，它把控制權交給了上層去實現，底層通過 面向接口 的原則只設計一個規范，而又使用者去實現；但框架功能里的細節是要有的，這類似於“模版方法”模式，底層框架實現了流程，而個性化的部分由上層去實現。
看jpa里的審計接口
public interface AuditorAware<T> {
/**
* Returns the current auditor of the application.
*
* @return the current auditor
*/
Optional<T> getCurrentAuditor();
}
上面這個泛型接口只有一個方法，需要讓上層開發人員根據自己的業務去實現它，比較返回一個當前登陸的用戶實體，或者返回用戶名稱，然后底層框架里直接使用這個AuditorAware接口的對象；當然如果你的底層只接收一個String類型的值，你也可以去派生一個個性化接口，讓上層開發人員去實現你的接口即可。
/**
* 返回用戶ID的標識接口,由程序使用者去實現.
*/
public interface UserIdAuditorAware extends AuditorAware<String> {
}
上面代碼更加准確的規定了AuditorAware是一個字符串的接口，只返回用戶ID即可。
@Component
public class CurrentUserAware implements UserIdAuditorAware {
@Autowired
ApplicationContext applicationContext;
@Override
public Optional<String> getCurrentAuditor() {
ServletRequestAttributes requestAttributes = (ServletRequestAttributes) RequestContextHolder.getRequestAttributes();
HttpServletRequest request = requestAttributes.getRequest();
return Optional.of(request.getSession().getAttribute("id").toString());
}
}
我們的底層代碼會使用它的getCurrentAuditor()返回值 ，它是一個字符串。
public Object execute(String sourceId, Integer timeout, TimeUnit unit) {
Assert.notNull(sourceId, "sourceId不能為空");
String key = getKey(sourceId);
String user = auditorAware.getCurrentAuditor().orElse(null);
Assert.notNull(user, "AuditorAware實例返回的值為空");
// 代碼略
}
對於一個小小的功能，我們在經過思考之后，對於之前學過的東西進行總結，你可能會想法某種設計模式、某個算法、某個原則、在使用它們之后，讓你的代碼擴展性更好，這種代碼也仿佛有了生命！