Java 中實例化類的動作，你是否還是一成不變 new 對應對象呢？
經手的項目多了，代碼編寫量自然會增加，漸漸的會對設計模式產生感覺。
怎樣使書寫出來的類實例化動作，高內聚，低耦合，又兼具一定的擴展能力呢？
本文試圖從幾段鮮活的代碼入手，給大家呈現不一樣的 Java 實例化類。
下面代碼取自 com.google.zxing 源碼實現：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
|
public BitMatrix encode(String contents, BarcodeFormat format, int width, int height, Map<EncodeHintType, ?> hints) throws WriterException { Object writer; switch(format.ordinal()) { case 1: writer = new AztecWriter(); break; case 2: writer = new CodaBarWriter(); break; case 3: writer = new Code39Writer(); break; case 4: case 10: case 13: case 14: default: throw new IllegalArgumentException("No encoder available for format " + format); case 5: writer = new Code128Writer(); break; case 6: writer = new DataMatrixWriter(); break; case 7: writer = new EAN8Writer(); break; case 8: writer = new EAN13Writer(); break; case 9: writer = new ITFWriter(); break; case 11: writer = new PDF417Writer(); break; case 12: writer = new QRCodeWriter(); break; case 15: writer = new UPCAWriter(); break; case 16: writer = new UPCEWriter(); } return ((Writer)writer).encode(contents, format, width, height, hints); } |
其中的 BarcodeFormat 是這樣的：
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
public enum BarcodeFormat { AZTEC, CODABAR, CODE_39, CODE_93, CODE_128, DATA_MATRIX, EAN_8, EAN_13, ITF, MAXICODE, PDF_417, QR_CODE, RSS_14, RSS_EXPANDED, UPC_A, UPC_E, UPC_EAN_EXTENSION; private BarcodeFormat() { }} |
源碼提供的功能是將信息通過幾種不同類型條形碼 Wirter 輸出為位矩陣，然后輸出到圖片上面，形成隨處可見的各種類型的條形碼。
BitMatrix bitMatrix = new MultiFormatWriter().encode(_text, BarcodeFormat.QR_CODE, qrcodeWidth, qrcodeHeight, hints);
MatrixToImageWriter.writeToFile(bitMatrix, qrcodeFormat, QrcodeFile);
源碼作者在這里使用了JDK 1.5 中引入的新特性 enum 枚舉類，編寫了BarcodeFormat類，其中定義了不同類型的條形碼的屬性。
調用 MultiFormatWriter.encode() 根據入參 BarcodeFormat.xx 在枚舉類中的序號，來實例化具體的類。
|
1
2
3
4
5
6
7
8
9
10
11
|
switch(format.ordinal()) {case 1: writer = new AztecWriter(); break;case 2: writer = new CodaBarWriter(); break;case 3: writer = new Code39Writer(); break;............... |
這些條形碼 Writer 類，同時都實現了抽象接口 Writer 的 兩個encode()方法。
|
1
2
3
4
5
|
public interface Writer { BitMatrix encode(String var1, BarcodeFormat var2, int var3, int var4) throws WriterException; BitMatrix encode(String var1, BarcodeFormat var2, int var3, int var4, Map<EncodeHintType, ?> var5) throws WriterException;} |
具體的條形碼 Wirter 類內部根據不同類型的條形碼規(guī)則，進行不同的邏輯。
使用者不需要過多的關注內部的實現，需要產生什么樣子的條形碼，入參選用合適的條形碼類型即可，筆者上述的例子里面實現的是二維碼。
在來看經典 MVC 框架 Webwork 動態(tài)實例化類的一段方法代碼:
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
private static Configuration getDefaultConfiguration () { if (defaultImpl == null) { defaultImpl = new DefaultConfiguration(); try { String className = getString("webwork.configuration"); if (!className.equals(defaultImpl.getClass().getName())) { try { defaultImpl = (Configuration) ObjectFactory.getObjectFactory().buildBean(Thread.currentThread().getContextClassLoader().loadClass(className)); } catch (Exception e) { LOG.error("Could not instantiate configuration", e); } } return defaultImpl; } catch (IllegalArgumentException localIllegalArgumentException) { } } } |
源碼取自 webwork-core,可能很多看客老爺沒有聽聞 Webwork, 但是對 Struts 應該是如雷貫耳，Struts2 核心改寫自 Webwork。
上述源碼提供的功能為實例化用戶自己定義的 配置文件讀取類，該定義是在配置文件當中。
源碼作者在這里使用 Thread.currentThread().getContextClassLoader().loadClass(className) 線程中類加載器，動態(tài)實例化自定義配置文件讀取類，可謂是效率最高的一種做法。
類加載器的委托鏈：SystemClassloader -> ExtensionClassloader -> BootstrapClassloader
委派鏈左邊的ClassLoader就可以很自然的使用右邊的ClassLoader所加載的類，類加載的機制為判斷自已是否加載該類，沒有在詢問上級。
而這三個類加載器分別對應著編譯器去尋找類文件的優(yōu)先級別和不同的路徑：
- BootClassLoader 它是用C++編寫的，從%jre%/lib目錄中加載類，或者運行時用-Xbootclasspath指定目錄來加載。是編譯器最優(yōu)先尋找class的地方
- ExtClassLoader 從%jre%/lib/ext目錄加載類，或者運行時用-Djava.ext.dirs制定目錄來加載。是編譯器次優(yōu)先尋找class的地方
- SystemClassloader 也就是我們常說的AppClassloader ,它對應當前路徑，所以也是編譯器默認找class的地方。
平時項目中使用的 Class.forname() 會從 BootstrapClassloader 開始詢問，是最消耗資源的。
源碼作者在這里采用線程類加載器，對應為 SystemClassloader ，效率無疑是最高的。
