在Java 8之中,除了Lambda、日期時間API等幾個顯著的特性,在標準API的許多角落,隱約可察覺Java努力說行話的企圖,無論是日期時間、高階排序、Stream等 API,都可看到努力展現DSL的設計,Java語言本身的特性,其實並不適合創建DSL這種事,然而更因為如此,從努力說行話的Java中,更可以看到DSL設計時應注意的本質。

程式庫設計就是語言設計

DSL此一名詞興起已有一段時間,指的是特定領域使用的特定語言,談到DSL設計,似乎許多開發者就會聯想起Ruby、Groovy、Scala等極力支援簡潔語法、meta-programming的語言,談到Java,大概就是提到XML,因為XML可用來建立外部(External)DSL,而Java提供了分析XML的程式庫,不必為XML撰寫特定的語言處理程式,至於創建以Java為宿主(host)語言的內部(Internal)DSL,似乎總不容易沾上邊。

Java不適合創建DSL的原因很明顯,第一,它不夠簡潔,根本就是囉嗦──型態宣告囉嗦、方法呼叫囉嗦,連後來號稱要減輕型態宣告負擔的泛型,也只有囉嗦兩字可以形容;第二個原因是自由度不夠,每個物件都得是一個模子(也就是類別)印出來的,不能說改就改,模子本身也是如此。在Java的世界裏似乎沒有DSL,只是充滿了程式庫、框架,而這正是Java過去歷史的象徵,Java中充滿了為各種領域而設計的各種程式庫與框架。

對於程式庫或框架,一般開發者的印象是可重用功能的集中處,開發者也都知道,在程式庫的使用過程中,都各有規則與流程必須遵守,越是特定領域的程式庫,越是如此,無異是程式語言的擴充。

在我之前專欄〈現代程式庫的多重角色〉中就探討過,擴充語法或語義在近來的程式庫設計中,越來越見其重要性,事實上在貝爾實驗室(Bell Labs)流傳,因C++創建者Stroustrup, Bjarne的引用,而廣為人知的一句話也談到:「程式庫設計就是語言設計(Library design is language design)」。

實際上,如果曾在Ruby、Groovy、Scala等語言中試著自訂內部DSL,也就會知道,內部DSL的本質,其實就是具有巧妙API設計的程式庫,如果語言本身的靈活性與自由度夠,在API設計時儘量接近自然語言或特定領域行話,這麼一來,在閱讀程式碼時,就能避免意識到宿主語言功能上「如何」達到,突顯程式想做些「什麼」,甚至不懂程式的特定領域專業人士,也可以看懂程式內容。

不只對開發者隱藏細節

Java不是沒說過特定領域行話,只是對象是著重在特定領域的開發者,像是測試領域,這時想到的,就是元老級的JUnit,測試套件(Test suite)、測試案例(Test case)等領域詞彙,只不過,測試用的程式碼看起來就像是……程式碼,即使是最後斷言測試,例如:assertTrue(names.contains("Justin") && names.contains("Monica") && names.contains("Irene")),如果不是開發者來觀看,通常馬上會意識到這是Java程式碼,而產生閱讀抗拒。

在《松本行弘談程式世界的未來》中,談到:「設計API時,如果抱著『這是在設計新DSL』的想法,或許會有全新的體認也說不一定」。程式庫設計的本質,就是隱藏細節,只是這次不是對開發者隱藏細節,而是為非開發者隱藏細節,就上例而言,可以隱藏List的API與&&判斷的細節,設計為assertThat(names, hasItems("Justin", "Monica", "Irene"))的形式,Harmcrest就是這樣設計的,在Java 8的高階排序API中,也運用了類似的技巧,像是words.sort(nullsFirst(reverseOrder()))。

那麼,hasItems實際上隱藏了什麼呢?一個測試領域開發者的詞彙Matcher,也就是斷言比較器,開發者會知道這是什麼,但非開發者不清楚,那麼reverseOrder、nullsFirst隱藏了什麼?一個排序領域開發者的詞彙Comparator,Java開發者都知道它在排序上的作用,只是現在得將之隱藏起來,因為非開發者的語意模型(Semantic Model)中不存在這個詞彙。

在Martin Fowler的《Domain-Specific Languages》中強調了,語意模型必須與DSL區分,藉由中介的建造器(Builder)來建構出語意模型實例,方才看過的hasItems、nullsFirst、reverseOrder,就是一種建造器,這邊的建造器只是一個名詞,並非設計模式中的建造器,當然,運用設計模式中的建造器模式,也是一種常見的方式,特別是加上了方法鏈結(Method chaining)的設計,更是過去為人知曉,Java中創建DSL的主要方式之一。

突顯領域中的名詞與動作

過去Java建立內部DSL的方式很有限,主要是隱藏語意模型建立的過程,能介入這過程的方式,就是指定某些值,而值只有基本型態與物件兩種選擇。

如果想在這些過程中自訂一些動作,那就得使用醜陋的匿名類別語法。guava-libraries的FluentIterable其中一個例子,在Java 8的Lambda還沒出現之前,使用它不是沒有效益,只不過受到匿名類別語法太多的干擾,看來就不太像個DSL(但本質上是了);想在過程中自訂一些動作,另一個例子就是框架,只不過,這仍然是Java開發者才會用的大傢伙。

語意模型基本上是領域中的名詞,藉由將方法等API設計為動詞,因而得以串聯起來而像個語言,只不過只透過方法等API設計,可運用的動詞就受到能接受的名詞之限制,而動詞本身也因而容易太具體,即使只是對特定領域的開發者隱藏細節,能實現DSL的場合也是受到相當的限制。

在Java 8中加入Lambda之後,這個限制得到解放,因為可以將程式碼當成資料傳遞(Code as data),也就表示可以自訂動作來介入DSL的流程了。

Java 8中最經典的Stream API,還是得再談一次,for、while等迴圈機制是程式語言面的元素,而filter、map對使用者隱藏了這些元素。以filter為例,它接受的Predicate實例,其實本質上與hasItems傳回的Matcher相似,只不過你僅能指定值給hasItems,來建立一個比對動作固定的Matcher,你卻能使用Lambda等語法來指定Predicate的比對動作。

因此,現在動詞可以不用過於具體,而可以抽象化為filter、map等動詞,程式撰寫時,就可以突顯特定領域中的動作,這就是Java 8標準API中,Stream、Optional、CompletableFuture、Comparator等API都開始像個DSL的原因了。

透過適當的設計,加入更多DSL的元素,像是文脈、語句、階層等,實現更特定領域的DSL就成了可能,在《Java 8 Lambdas》中,就以JavaScript的Jasmine為模仿對象,用Java設計了一個極為相似的BDD(Dehavior-driven development)框架。

DSL設計對象是人,不是機器

身為一名開發者,關心的事情當然是「如何」完成功能,然而,身為一名使用者,只關心功能是「什麼」,因而有個玩笑話(某些程度上也是事實)是:「用什麼技術不重要,東西會動才是最重要的」,確實也是如此,程式設計表面上是告知機器如何動作,然而實際上是要想清楚「人們實際要求什麼、這些要求的本質是什麼、以及達成這些要求的詳細步驟是什麼的過程」,松本行弘在《松本行弘談程式世界的未來》就是如此提到。

DSL的發展,似乎反映了從機器到人這樣的過程,開始是「可重用功能的集中處」,發展到有時是為了「限制或避免語言特性」,接著進入「擴充語法或語義」,然後有了特定領域語言的考量,更多關心從HOW轉移到了WHAT,無論那是開發者重視的WHAT,或者只是一名單純使用者的WHAT。

當更多設計的對象是人而不是機器時,語言在DSL上的可能性,往往超越了語言創建者的想像,Ruby之父就曾對此感到驚訝,囉嗦又不靈活的Java能開始講行話,也就不足為奇了!

作者簡介


Advertisement

更多 iThome相關內容