在學習一門語言的過程中,有個實際可開發的小專案,有助於語言的熟悉與應用,也許寫個文字編輯器之類的桌面視窗程式,或者是開發個留言版、部落格。現在前端當道,許多人也會以手機App為目標。

在此同時,寫個命令列介面(Command-line interface,CLI)也是個不錯選擇,兼具實用性。

管理命令列選項

忘了是哪位大師曾經說過,每當他學習一門程式語言時,必定寫個文字編輯器作為練習,我也曾經在我的書中介紹過視窗介面,具體開發一個簡單的文字編輯器專案,作為讀者的練習對象。

然而,在Web應用程式與手機App相繼流行起來之後,視窗應用程式受到的關注逐漸式微,我也就順勢在後續改版書籍時,將視窗介面的介紹從書中移除了,從那之後,我就一直在思考著,還有什麼好的主題,可以讓讀者在語言的初學階段,就能開發並藉此熟悉語言的相關元素、思考風格與典範呢?

無論是視窗、Web應用程式,或者是手機App,都是個好的練習對象,只是都需要額外學習一些語言之外的API方案,那麼來開發一個命令列介面如何?

畢竟語言介紹時,多半是從在命令列顯示Hello, World的小程式開始,而後續的練習程式為了要有互動性,往往也是在命令列中進行一些輸入與輸出,開發命令列介面作為練習,實際應用場合也多,就算是視窗應用程式,為了方便與其他應用程式結合,多半也要提供這樣的執行模式。

想要管理命令列選項,我們首先要決定接受的選項格式。

常見的單破折號選項,像是tar -zxvf foo.tar.gz是POSIX風格(POSIX like options),破折號之後,跟隨著的單一字元,各代表一個選項(有時空一格加上對應值)。

另一種常見的雙折號長名稱選項,像是du --human-readable --max-depth=1為GNU風格(GNU like long options),擁有比較好的可讀性,在GNU的命令列介面標準(https://goo.gl/kbPFsS)中提到,基於使用者友善考量,建議對-A這類的短選項,也提供對應的--almost-all長選項名稱。

實際上,每種應用程式基於不同的考量,可能採取的選項風格也不相同,例如Java中常見的-Djava.awt.headless=true特性選項,同時具備短選項與值的gcc -O2 foo.c風格,或是單折號長名稱的ant -projecthelp風格等,不同選項風格牽涉到不同的剖析方式,協助(Help)訊息的輸出方式也不同,想要寫個通用的命令列介面,會比想像中複雜的多,不單只是要熟悉語言元素,還會有設計上的考量。

定義選項

如果現在決定要使用單折號長名稱,像是-help可以輸出協助訊息的話,以下的簡單程式,就算是第一次學習程式語言的初學者,應該都覺得不難:

if(args.length != 0 && "-help".equals(args[0])) {
out.println("顯示協助訊息");
}

接著試著進一步想像,若加入更多選項會如何?像是加入-version來顯示版本訊息?這麼一來,就會發現有更多的if判斷式,而用來檢查選項的條件式會開始出現重複,這時可將重複的程式碼抽取出來成為hasOption(String[] args, String option),之後就可以使用if(hasOption(args, "-version"))來避免重複,而且語意上比較清晰。

現在考慮使用者想查詢某個選項的作用,這就須為每個選項名稱加上描述文字,也許選項還有必要(Required)與選用(Optional)之別,既然如此,就定義一個Option類別來封裝選項的相關欄位吧!

使用者也許會使用-version來取得描述,程式面上,也就需要使用字串來取得對應的Option物件,這可以使用Map<String, Option>資料結構,只不過既然是用來管理一組Option物件,何不定義一個Options物件呢?如此一來,Options還可以提供一個addOption(String name, String desc)方法方便新增選項,讓開發者不用自行建立Option物件,例如:

Options options = new Options();
options.addOption("-help", "show help messages");
options.addOption("-version", "show version messages");

隨著選項可能性的增加,也許考慮使用流暢API風格,讓選項在建立時的程式碼,更能表達自身意圖,例如,使用OptionBuilder.withArgName("file").hasArg().withDescription("use given file for log" ).create( "-logfile" )來表示,將會建立一個具有引數(file)、描述的-logfile選項。

剖析選項

現在我們來考慮一下,像options.addOption("-help", "show help messages"),會有什麼問題?如果另一個開發者想要使用這個命令列介面,來管理程式,那麼,目前的方案等於強迫他使用單折號長名稱的風格。在建立選項時應該中立,不偏向哪一種風格,也就是使用options.addOption("help", "show help messages")的方式。

這麼一來,針對目前單折號長名稱的方案,可定義一個Parser,判斷使用者輸入的選項是否以單折號開頭,若是的話,傳回一個POSIXCommandLine,由它來負責將-help的選項,對應到Option("help", "show help messages")物件這類的工作。

接著,可以在Parser中定義雙折號的判斷,傳回GnuCommandLine之類的物件,你可以定義CommandLine介面,讓POSIXCommandLine、GnuCommandLine都實作此介面,以便在剖析出不同的選項風格時,傳回不同的實作,進一步地,還可以定義CommandLineParser介面,使用這個命令列介面管理程式的開發者,可以定義自己的CommandLineParser、CommandLine實作,建立自己的選項剖析過程。

處理命令列的格式化其實也是個麻煩,為了方便開發者輸出協助訊息,可以定義HelpFormatter,接受Options物件,提供各種printHelp方法,根據不同的選項風格,輸出不同的訊息內容。

不想重新打造輪子?

也許不見得是練習,而是應用程式確實需要一個命令列介面,試著自己寫的好處是,程式量身打造,不用額外相依於其他的程式庫套件,然而,如果想要有個立即可用的方案,主流程式語言都會有相應的開放原始碼方案。

實際上,先前描述的重構流程(可參考https://goo.gl/uc6RcY),是特意模仿Apache Commons CLI的風格,透過這樣的重構過程,也就能瞭解到,為何官方文件中一開始就提到處理命令列選項,會需要:選項的定義(Definition)、剖析(Parsing),以及詢問(Interrogation)這三個階段。

Commons CLI是個相對小型的程式庫,然而,原始碼規模相對來說也比較小,在試著模仿它的風格撰寫出自己的方案之後,可以看看原始碼做個比較;如果需要的命令列介面更為複雜,像是考量到預設值、大小寫處理、國際化等需求,或者程式面上,會想要使用標註(Annotation),讓程式碼更為簡明時,可以考慮使用JCommander程式庫。

當然,不同程式庫會有不同風格,其他語言也會有相對應的方案,在Python中,從3.2版本之後,甚至提供了標準模組argparse(此標準模組也回饋至Python 2.7),讓開發者便於處理命令列引數,官方網站也提供了Argparse Tutorial(https://goo.gl/cnSV6v)進行詳盡的說明,類似地,可以試著自己開發一個簡單的原型,再看看argparse原始碼作為比較,這將會是個有趣的體驗!

作者簡介


Advertisement

更多 iThome相關內容