3. 搞定收工,PropertyEditor就到這

YourBatman發表於2020-12-17

分享、成長,拒絕淺藏輒止。搜尋公眾號【BAT的烏托邦】,回覆關鍵字專欄有Spring技術棧、中介軟體等小而美的原創專欄供以免費學習。本文已被 https://www.yourbatman.cn 收錄。

✍前言

你好,我是YourBatman。

上篇文章介紹了PropertyEditor在型別轉換裡的作用,以及舉例說明了Spring內建實現的PropertyEditor們,它們各司其職完成 String <-> 各種型別 的互轉。

在知曉了這些基礎知識後,本文將更進一步,為你介紹Spring是如何註冊、管理這些轉換器,以及如何自定義轉換器去實現私有轉換協議。

版本約定

  • Spring Framework:5.3.1
  • Spring Boot:2.4.0

✍正文

稍微熟悉點Spring Framework的小夥伴就知道,Spring特別擅長API設計、模組化設計。字尾模式是它常用的一種管理手段,比如xxxRegistry註冊中心在Spring內部就有非常多:

xxxRegistry用於管理(註冊、修改、刪除、查詢)一類元件,當元件型別較多時使用註冊中心統一管理是一種非常有效的手段。誠然,PropertyEditor就屬於這種場景,管理它們的註冊中心是PropertyEditorRegistry

PropertyEditorRegistry

它是管理PropertyEditor的中心介面,負責註冊、查詢對應的PropertyEditor。

// @since 1.2.6
public interface PropertyEditorRegistry {

    // 註冊一個轉換器:該type型別【所有的屬性】都將交給此轉換器去轉換(即使是個集合型別)
    // 效果等同於呼叫下方法:registerCustomEditor(type,null,editor);
	void registerCustomEditor(Class<?> requiredType, PropertyEditor propertyEditor);
	// 註冊一個轉換器:該type型別的【propertyPath】屬性將交給此轉換器
	// 此方法是重點,詳解見下文
	void registerCustomEditor(Class<?> requiredType, String propertyPath, PropertyEditor propertyEditor);
	// 查詢到一個合適的轉換器
	PropertyEditor findCustomEditor(Class<?> requiredType, String propertyPath);
	
}

說明:該API是1.2.6這個小版本新增的。Spring 一般 不會在小版本里新增核心API以確保穩定性,但這並非100%。Spring認為該API對使用者無感的話(你不可能會用到它),增/減也是有可能的

此介面的繼承樹如下:

值得注意的是:雖然此介面看似實現者眾多,但其實其它所有的實現關於PropertyEditor的管理部分都是委託給PropertyEditorRegistrySupport來管理,無一例外。因此,本文只需關注PropertyEditorRegistrySupport足矣,這為後面的高階應用(如資料繫結、BeanWrapper等)打好堅實基礎。

用不太正確的理解可這麼認為:PropertyEditorRegistry介面的唯一實現只有PropertyEditorRegistrySupport

PropertyEditorRegistrySupport

它是PropertyEditorRegistry介面的實現,提供對default editorscustom editors的管理,最終主要為BeanWrapperImplDataBinder服務。

一般來說,Registry註冊中心內部會使用多個Map來維護,代表登錄檔。此處也不例外:

// 裝載【預設的】編輯器們,初始化的時候會註冊好
private Map<Class<?>, PropertyEditor> defaultEditors;
// 如果想覆蓋掉【預設行為】,可通過此Map覆蓋(比如處理Charset型別你不想用預設的編輯器處理)
// 通過API:overrideDefaultEditor(...)放進此Map裡
private Map<Class<?>, PropertyEditor> overriddenDefaultEditors;

// ======================註冊自定義的編輯器======================
// 通過API:registerCustomEditor(...)放進此Map裡(若沒指定propertyPath)
private Map<Class<?>, PropertyEditor> customEditors;
// 通過API:registerCustomEditor(...)放進此Map裡(若指定了propertyPath)
private Map<String, CustomEditorHolder> customEditorsForPath;

PropertyEditorRegistrySupport使用了4個 Map來維護不同來源的編輯器,作為查詢的 “資料來源”

這4個Map可分為兩大組,並且有如下規律:

  • 預設編輯器組:defaultEditors和overriddenDefaultEditors
    • overriddenDefaultEditors優先順序 高於 defaultEditors
  • 自定義編輯器組:customEditors和customEditorsForPath
    • 它倆為互斥關係

細心的小夥伴會發現還有一個Map我們還未提到:

private Map<Class<?>, PropertyEditor> customEditorCache;

從屬性名上理解,它表示customEditors屬性的快取。那麼問題來了:customEditors和customEditorCache的資料結構一毛一樣(都是Map),談何快取呢?直接從customEditors裡獲取值不更香嗎?

customEditorCache作用解釋

customEditorCache用於快取自定義的編輯器,輔以成員屬性customEditors屬性一起使用。具體(唯一)使用方式在私有方法:根據型別獲取自定義編輯器PropertyEditorRegistrySupport#getCustomEditor

private PropertyEditor getCustomEditor(Class<?> requiredType) {
	if (requiredType == null || this.customEditors == null) {
		return null;
	}
	PropertyEditor editor = this.customEditors.get(requiredType);

	// 重點:若customEditors沒有並不代表處理不了,因為還得考慮父子關係、介面關係
	if (editor == null) {
		// 去快取裡查詢,是否存在父子類作為key的情況
		if (this.customEditorCache != null) {
			editor = this.customEditorCache.get(requiredType);
		}
	
		// 若快取沒命中,就得遍歷customEditors了,時間複雜度為O(n)
		if (editor == null) {
			for (Iterator<Class<?>> it = this.customEditors.keySet().iterator(); it.hasNext() && editor == null;) {
				Class<?> key = it.next();
				if (key.isAssignableFrom(requiredType)) {
					editor = this.customEditors.get(key);
					if (this.customEditorCache == null) {
						this.customEditorCache = new HashMap<Class<?>, PropertyEditor>();
					}
					this.customEditorCache.put(requiredType, editor);
				}
			}
		}
	}
	return editor;
}

這段邏輯不難理解,此流程用一張圖可描繪如下:

因為遍歷customEditors屬於比較重的操作(複雜度為O(n)),從而使用了customEditorCache避免每次出現父子類的匹配情況就去遍歷一次,大大提高匹配效率。

什麼時候customEditorCache會發揮作用?也就說什麼時候會出現父子類匹配情況呢?為了加深理解,下面搞個例子玩一玩

程式碼示例

準備兩個具有繼承關係的實體型別

@Data
public abstract class Animal {
    private Long id;
    private String name;
}

public class Cat extends Animal {

}

書寫針對於父類(父介面)型別的編輯器:

public class AnimalPropertyEditor extends PropertyEditorSupport {

    @Override
    public String getAsText() {
        return null;
    }

    @Override
    public void setAsText(String text) throws IllegalArgumentException {
    }
}

說明:由於此部分只關注查詢/匹配過程邏輯,因此對編輯器內部處理邏輯並不關心

註冊此編輯器,對應的型別為父型別:Animal

@Test
public void test5() {
    PropertyEditorRegistry propertyEditorRegistry = new PropertyEditorRegistrySupport();
    propertyEditorRegistry.registerCustomEditor(Animal.class, new AnimalPropertyEditor());

	// 付型別、子型別均可匹配上對應的編輯器
    PropertyEditor customEditor1 = propertyEditorRegistry.findCustomEditor(Cat.class, null);
    PropertyEditor customEditor2 = propertyEditorRegistry.findCustomEditor(Animal.class, null);
    System.out.println(customEditor1 == customEditor2);
    System.out.println(customEditor1.getClass().getSimpleName());
}

執行程式,結果為:

true
AnimalPropertyEditor

結論

  • 型別精確匹配優先順序最高
  • 若沒精確匹配到結果且本型別的父型別已註冊上去,則最終也會匹配成功


customEditorCache的作用可總結為一句話:幫助customEditors屬性裝載對已匹配上的子型別的編輯器,從而避免了每次全部遍歷,有效的提升了匹配效率。

值得注意的是,每次呼叫API向customEditors新增新元素時,customEditorCache就會被清空,因此因儘量避免在執行期註冊編輯器,以避免快取失效而降低效能

customEditorsForPath作用解釋

上面說了,它是和customEditors互斥的。

customEditorsForPath的作用是能夠實現更精準匹配,針對屬性級別精準處理。此Map的值通過此API註冊進來:

public void registerCustomEditor(Class<?> requiredType, String propertyPath, PropertyEditor propertyEditor);

說明:propertyPath不能為null才進此處,否則會註冊進customEditors嘍

可能你會想,有了customEditors為何還需要customEditorsForPath呢?這裡就不得不說兩者的最大區別了:

  • customEditors:粒度較粗,通用性強。key為型別,即該型別的轉換全部交給此編輯器處理
    • 如:registerCustomEditor(UUID.class,new UUIDEditor()),那麼此編輯器就能處理全天下所有的String <-> UUID 轉換工作
  • customEditorsForPath:粒度細精確到屬性(欄位)級別,有點專車專座的意思
    • 如:registerCustomEditor(Person.class, "cat.uuid" , new UUIDEditor()),那麼此編輯器就有且僅能處理Person.cat.uuid屬性,其它的一概不管

有了這種區別,註冊中心在findCustomEditor(requiredType,propertyPath)匹配的時候也是按照優先順序順序執行匹配的:

  1. 若指定了propertyPath(不為null),就先去customEditorsForPath裡找。否則就去customEditors裡找
  2. 若沒有指定propertyPath(為null),就直接去customEditors裡找

為了加深理解,講上場景用程式碼實現如下。

程式碼示例

建立一個Person類,關聯Cat

@Data
public class Cat extends Animal {
    private UUID uuid;
}

@Data
public class Person {
    private Long id;
    private String name;
    private Cat cat;
}

現在的需求場景是:

  • UUID型別統一交給UUIDEditor處理(當然包括Cat裡面的UUID型別)
  • Person類裡面的Cat的UUID型別,需要單獨特殊處理,因此格式不一樣需要“特殊照顧”

很明顯這就需要兩個不同的屬性編輯器來實現,然後組織起來協同工作。Spring內建了UUIDEditor可以處理一般性的UUID型別(通用),而Person 專用的 UUID編輯器,自定義如下:

public class PersonCatUUIDEditor extends UUIDEditor {

    private static final String SUFFIX = "_YourBatman";

    @Override
    public String getAsText() {
        return super.getAsText().concat(SUFFIX);
    }

    @Override
    public void setAsText(String text) throws IllegalArgumentException {
        text = text.replace(SUFFIX, "");
        super.setAsText(text);
    }
}

向註冊中心註冊編輯器,並且書寫測試程式碼如下:

@Test
public void test6() {
    PropertyEditorRegistry propertyEditorRegistry = new PropertyEditorRegistrySupport();
    // 通用的
    propertyEditorRegistry.registerCustomEditor(UUID.class, new UUIDEditor());
    // 專用的
    propertyEditorRegistry.registerCustomEditor(Person.class, "cat.uuid", new PersonCatUUIDEditor());


    String uuidStr = "1-2-3-4-5";
    String personCatUuidStr = "1-2-3-4-5_YourBatman";

    PropertyEditor customEditor = propertyEditorRegistry.findCustomEditor(UUID.class, null);
    // customEditor.setAsText(personCatUuidStr); // 拋異常:java.lang.NumberFormatException: For input string: "5_YourBatman"
    customEditor.setAsText(uuidStr);
    System.out.println(customEditor.getAsText());

    customEditor = propertyEditorRegistry.findCustomEditor(Person.class, "cat.uuid");
    customEditor.setAsText(personCatUuidStr);
    System.out.println(customEditor.getAsText());
}

執行程式,列印輸出:

00000001-0002-0003-0004-000000000005
00000001-0002-0003-0004-000000000005_YourBatman

完美。

customEditorsForPath相當於給你留了鉤子,當你在某些特殊情況需要特殊照顧的時候,你可以藉助它來搞定,十分的方便。

此方式有必要記住並且嘗試,在實際開發中使用得還是比較多的。特別在你不想全域性定義,且要確保向下相容性的時候,使用抽象介面型別 + 此種方式縮小影響範圍將十分有用

說明:propertyPath不僅支援Java Bean導航方式,還支援集合陣列方式,如Person.cats[0].uuid這樣格式也是ok的

PropertyEditorRegistrar

Registrar:登記員。它一般和xxxRegistry配合使用,其實核心還是Registry,只是運用了倒排思想遮蔽一些內部實現而已。

public interface PropertyEditorRegistrar {
	void registerCustomEditors(PropertyEditorRegistry registry);
}

同樣的,Spring內部也有很多類似實現模式:

PropertyEditorRegistrar介面在Spring體系內唯一實現為:ResourceEditorRegistrar。它可值得我們絮叨絮叨。

ResourceEditorRegistrar

從命名上就知道它和Resource資源有關,實際上也確實如此:主要負責將ResourceEditor註冊到註冊中心裡面去,用於處理形如Resource、File、URI等這些資源型別。

你配置classpath:xxx.xml用來啟動Spring容器的配置檔案,String -> Resource轉換就是它的功勞嘍

唯一構造器為:

public ResourceEditorRegistrar(ResourceLoader resourceLoader, PropertyResolver propertyResolver) {
	this.resourceLoader = resourceLoader;
	this.propertyResolver = propertyResolver;
}
  • resourceLoader:一般傳入ApplicationContext
  • propertyResolver:一般傳入Environment

很明顯,它的設計就是服務於ApplicationContext上下文,在Bean建立過程中輔助BeanWrapper實現資源載入、轉換。

BeanFactory在初始化的準備過程中就將它例項化,從而具備資源處理能力:

AbstractApplicationContext:

	protected void prepareBeanFactory(ConfigurableListableBeanFactory beanFactory) {
		
		...
		beanFactory.setBeanExpressionResolver(new StandardBeanExpressionResolver(beanFactory.getBeanClassLoader()));
		beanFactory.addPropertyEditorRegistrar(new ResourceEditorRegistrar(this, getEnvironment()));
		...
	}

這也是PropertyEditorRegistrar在Spring Framework的唯一使用處,值的關注。

PropertyEditor自動發現機制

最後介紹一個使用中的奇淫小技巧:PropertyEditor自動發現機制。

一般來說,我們自定義一個PropertyEditor是為了實現自定義型別 <-> 字串的自動轉換,它一般需要有如下步驟:

  1. 為自定義型別寫好一個xxxPropertyEditor(實現PropertyEditor介面)
  2. 將寫好的編輯器註冊到註冊中心PropertyEditorRegistry

顯然步驟1屬個性化行為無法替代,但步驟2屬於標準行為,重複勞動是可以標準化的。自動發現機制就是用來解決此問題,對自定義的編輯器制定瞭如下標準:

  1. 實現了PropertyEditor介面,具有空構造器
  2. 與自定義型別同包(在同一個package內),名稱必須為:targetType.getName() + "Editor"

這樣你就無需再手動註冊到註冊中心了(當然手動註冊了也不礙事),Spring能夠自動發現它,這在有大量自定義型別編輯器的需要的時候將很有用。

說明:此段核心邏輯在BeanUtils#findEditorByConvention()裡,有興趣者可看看

值得注意的是:此機制屬Spring遵循Java Bean規範而單獨提供,在單獨使用PropertyEditorRegistry時並未開啟,而是在使用Spring產品級能力TypeConverter時有提供,這在後文將有體現,歡迎保持關注。

✍總結

本文在瞭解PropertyEditor基礎支援之上,主要介紹了其註冊中心PropertyEditorRegistry的使用。PropertyEditorRegistrySupport作為其“唯一”實現,負責管理PropertyEditor,包括通用處理和專用處理。最後介紹了PropertyEditor的自動發現機制,其實在實際生產中我並建議使用自動機制,因為對於可能發生改變的因素,顯示指定優於隱式約定

關於Spring型別轉換PropertyEditor相關內容就介紹到這了,雖然它很“古老”但並沒有退出歷史舞臺,在排查問題,甚至日常擴充套件開發中還經常會碰到,因此強烈建議你掌握。下面起將介紹Spring型別轉換的另外一個重點:新時代的型別轉換服務ConversionService及其周邊。


✔✔✔推薦閱讀✔✔✔

【Spring型別轉換】系列:

【Jackson】系列:

【資料校驗Bean Validation】系列:

【新特性】系列:

【程式人生】系列:

還有諸如【Spring配置類】【Spring-static】【Spring資料繫結】【Spring Cloud Netflix】【Feign】【Ribbon】【Hystrix】...更多原創專欄,關注BAT的烏托邦回覆專欄二字即可全部獲取,分享、成長,拒絕淺藏輒止。

有些專欄已完結,有些正在連載中,期待你的關注、共同進步

相關文章