幾個(gè)小伙伴在考慮下面這個(gè)各個(gè)語言都會(huì)遇到的問題：

問題：設(shè)計(jì)一個(gè)命令行參數(shù)解析API

一個(gè)好的命令行參數(shù)解析庫一般涉及到這幾個(gè)常見的方面：

1) 支持方便地生成幫助信息

2) 支持子命令，比如：git包含了push, pull, commit等多種子命令

3) 支持單字符選項(xiàng)、多字符選項(xiàng)、標(biāo)志選項(xiàng)、參數(shù)選項(xiàng)等多種選項(xiàng)和位置參數(shù)

4) 支持選項(xiàng)默認(rèn)值，比如：–port選項(xiàng)若未指定認(rèn)為5037

5) 支持使用模式，比如：tar命令的-c和-x是互斥選項(xiàng)，屬于不同的使用模式

經(jīng)過一番考察，小伙伴們發(fā)現(xiàn)了這個(gè)幾個(gè)有代表性的API設(shè)計(jì)：

1. getopt()：

getopt()是libc的標(biāo)準(zhǔn)函數(shù)，很多語言中都能找到它的移植版本。

12345678910111213141516171819202122

//Cwhile ((c = getopt(argc, argv, "ac:d:")) != -1) {????int this_option_optind = optind ? optind : 1;????switch (c) {????case 'a':????????printf ("option a");????????aopt = 1;????????break;????case 'c':????????printf ("option c with value '%s'", optarg);????????copt = optarg;????????break;????case 'd':????????printf ("option d with value '%s'", optarg);????????dopt = optarg;????????break;????case '?':????????break;????default:????????printf ("?? getopt returned character code 0%o ??", c);????}}

getopt()的核心是一個(gè)類似printf的格式字符串的命令行參數(shù)描述串，如上面的”ac:d:”定義了”a”, “c”，”d”3個(gè)命令行參數(shù)，其中，a是一個(gè)標(biāo)志符不需要參數(shù)，”c”和”d”需要跟參數(shù)。getopt()功能非常弱，只支持單個(gè)字符的標(biāo)志選項(xiàng)和參數(shù)選項(xiàng)。如果按上面的5點(diǎn)來比對(duì)，基本上只能說是勉強(qiáng)支持第3點(diǎn)，其他幾項(xiàng)只能靠程序自己來實(shí)現(xiàn)了，所以，想直接基于getopt()實(shí)現(xiàn)一個(gè)像git這樣復(fù)雜的命令行參數(shù)是不可能的，只有自己來做很多的解析工作。小伙伴們看過getopt()之后一致的評(píng)價(jià)是:圖樣圖森破。

2. Google gflags

接著，小伙伴們又發(fā)現(xiàn)了gflags這個(gè)Google出品C++命令行參數(shù)解析庫。

1234567891011121314151617181920212223

//C++DEFINE_bool(memory_pool, false, "If use memory pool");DEFINE_bool(daemon, true, "If started as daemon");DEFINE_string(module_id, "", "Server module id");DEFINE_int32(http_port, 80, "HTTP listen port");DEFINE_int32(https_port, 443, "HTTPS listen port");int main(int argc, char** argv) {????::google::ParseCommandLineFlags(&argc, &argv, true);????printf("Server module id: %s", FLAGS_module_id.c_str());????if (FLAGS_daemon) {??????printf("Run as daemon: %d", FLAGS_daemon);????}????if (FLAGS_memory_pool) {??????printf("Use memory pool: %d", FLAGS_daemon);????}????Server server;????return 0;}

小伙伴們看了后不由得感嘆“真心好用啊”！的確，gflags簡(jiǎn)單地通過幾個(gè)宏就定義了命令行選項(xiàng)，基本上很好的支持了上面提到的1，3，4這幾項(xiàng)，比起getopt()來強(qiáng)多了。對(duì)于類似cp這樣的小命令，gflags應(yīng)該是夠用了，但要達(dá)到git這種級(jí)別就顯得有些單薄了。

3. Ruby Commander

接下來小伙伴們又發(fā)現(xiàn)了Ruby Commander庫：

12345678910111213141516171819

//Ruby# :name is optional, otherwise uses the basename of this executableprogram :name, 'Foo Bar'program :version, '1.0.0'program :description, 'Stupid command that prints foo or bar.'command :bar do |c|??c.syntax = 'foobar bar [options]'??c.description = 'Display bar with optional prefix and suffix'??c.option '--prefix STRING', String, 'Adds a prefix to bar'??c.option '--suffix STRING', String, 'Adds a suffix to bar'??c.action do |args, options|????options.default :prefix => '(', :suffix => ')'????say "#{options.prefix}bar#{options.suffix}"??endend$ foobar bar# => (bar)$ foobar bar --suffix '}' --prefix '{'# => {bar}

Commander庫利用Ruby酷炫的語法定義了一種描述命令行參數(shù)的內(nèi)部DSL，看起來相當(dāng)高端大氣上檔次。除了上面的第5項(xiàng)之外，其他幾項(xiàng)都有很好的支持，可以說Commander庫的設(shè)計(jì)基本達(dá)到了git這種級(jí)別命令行參數(shù)解析的要求。只是，要搞懂Ruby這么炫的語法和這個(gè)庫的使用方法恐怕就不如getopt()和gflags容易了。有小伙伴當(dāng)場(chǎng)表示想要學(xué)習(xí)Ruby，但是也有小伙伴表示再看看其他庫再說。

4. Lisp cmdline庫

接下來，小伙伴們發(fā)現(xiàn)了Lisp方言Racket的cmdline庫。

1234567891011121314151617181920212223

//Lisp(parse-command-line "compile" (current-command-line-arguments)??`((once-each?????[("-v" "--verbose")??????,(lambda (flag) (verbose-mode #t))??????("Compile with verbose messages")]?????[("-p" "--profile")??????,(lambda (flag) (profiling-on #t))??????("Compile with profiling")])????(once-any?????[("-o" "--optimize-1")??????,(lambda (flag) (optimize-level 1))??????("Compile with optimization level 1")]?????[("--optimize-2")??????,(lambda (flag) (optimize-level 2))??????(("Compile with optimization level 2,"????????"which implies all optimizations of level 1"))])????(multi?????[("-l" "--link-flags")??????,(lambda (flag lf) (link-flags (cons lf (link-flags))))??????("Add a flag <lf> for the linker" "lf")]))???(lambda (flag-accum file) file)???'("filename"))

這是神馬浮云啊?括號(hào)套括號(hào)，看起來很厲害的樣子，但又不是很明白。看到這樣的設(shè)計(jì)，有的小伙伴連評(píng)價(jià)都懶得評(píng)價(jià)了，但也有的小伙伴對(duì)Lisp越發(fā)崇拜，表示Lisp就是所謂的終極語言了，沒有哪門語言能寫出這么不明覺歷的代碼來！小伙伴們正準(zhǔn)備打完收工，突然…

5. Node.js的LineParser庫

發(fā)現(xiàn)了Node.js的LineParser庫:

1234567891011121314151617181920212223242526272829303132333435

//JavaScriptvar meta = {????program : 'adb',????name : 'Android Debug Bridge',????version : '1.0.3',????subcommands : [ 'connect', 'disconnect', 'install' ],????options : {????????flags : [????????????[ 'h', 'help', 'print program usage' ],????????????[ 'r', 'reinstall', 'reinstall package' ],????????????[ 'l', 'localhost', 'localhost' ]????????],????????parameters : [????????????[ null, 'host', 'adb server hostname or IP address', null ],????????????[ 'p', 'port', 'adb server port', 5037 ]????????]????},????usages : [????????[ 'connect', ['host', '[port]'], null, 'connect to adb server', adb_connect ],????????[ 'connect', [ 'l' ], null, 'connect to the local adb server', adb_connect ],????????[ 'disconnect', null, null, 'disconnect from adb server', adb_disconnect ],????????[ 'install', ['r'], ['package'], 'install package', adb_install ],????????[ null, ['h'], null, 'help', adb_help ],????]};try {????var lineparser = require('lineparser');????var parser = lineparser.init(meta);????// adb_install will be invoked????parser.parse(['install', '-r', '/pkgs/bird.apk']);}catch (e) {????console.error(e);}

天啊！？這是什么？我和小伙伴們徹底驚呆了！短短十幾行代碼就獲得了上面5點(diǎn)的全面支持，重要的是小伙伴們居然一下子就看懂了，沒有任何的遮遮掩掩和故弄玄虛。本來以為Ruby和Lisp很酷，小伙伴們都想馬上去學(xué)Ruby和Lisp了，看到這個(gè)代碼之后怎么感覺前面全是在裝呢？有個(gè)小伙伴居然激動(dòng)得哭著表示：我寫代碼多年，以為再也沒有什么代碼可以讓我感動(dòng)，沒想到這段代碼如此精妙，我不由得要贊嘆了，實(shí)在是太漂亮了！

小伙伴們的故事講完了，您看懂了嗎？如果沒有看懂的話，正題開始了：

在絕大多數(shù)語言中數(shù)據(jù)和代碼可以說是涇渭分明，習(xí)慣C++、Java等主流語言的程序員很少去思考數(shù)據(jù)和代碼之間的關(guān)系。與多數(shù)語言不同的是Lisp以“數(shù)據(jù)即代碼，代碼即數(shù)據(jù)”著稱，Lisp用S表達(dá)式統(tǒng)一了數(shù)據(jù)和代碼的形式而獨(dú)樹一幟。Lisp奇怪的S表達(dá)式和復(fù)雜的宏系統(tǒng)讓許多人都感到Lisp很神秘，而多數(shù)Lisp教程要么強(qiáng)調(diào)函數(shù)式編程，要么鼓吹宏如何強(qiáng)大，反而掩蓋了Lisp真正本質(zhì)的東西，為此我曾寫過一篇《Lisp的永恒之道》介紹Lisp思想。

設(shè)計(jì)思想和具體技術(shù)的區(qū)別在于前者往往可以在不同的環(huán)境中以不同的形式展現(xiàn)出來。比如，熟悉函數(shù)式編程的程序員在理解了純函數(shù)的優(yōu)點(diǎn)后即使是用C語言也會(huì)更傾向于寫出無副作用的函數(shù)來，這就是函數(shù)式思想在命令式環(huán)境的應(yīng)用。所以，理解Lisp思想一定要能在非Lisp環(huán)境應(yīng)用，才算是融匯貫通。

如果真正理解了Lisp的本質(zhì)，那所謂的“數(shù)據(jù)即代碼，代碼即數(shù)據(jù)”一點(diǎn)兒也不神秘，這不就是我們每天打交道的配置文件嗎！？如果你還不是很理解的話，我們通過下面幾個(gè)問題慢慢分析：

1) 配置的本質(zhì)是什么？為什么要在程序中使用配置文件？

不知道你是否意識(shí)到了，我們每天都在使用的各種各樣的配置本質(zhì)上是一種元數(shù)據(jù)也是一種DSL，這和Lisp基于S表達(dá)式的“數(shù)據(jù)即代碼，代碼即數(shù)據(jù)”沒有本質(zhì)區(qū)別。在C++、Java等程序中引入配置文件的目的正是用DSL彌補(bǔ)通用語言表達(dá)能力和靈活性的不足。我知道不少人喜歡從計(jì)算的角度來看到程序和語言，似乎只有圖靈完備的語言如C++、Java、Python等才叫程序設(shè)計(jì)語言，而類似CSS和HTML這樣的東西根本不能叫做程序設(shè)計(jì)語言。其實(shí)，在我看來這種觀點(diǎn)過于狹隘，程序的本質(zhì)是語義的表達(dá)，而語義表達(dá)不一定要是計(jì)算。

2) 配置是數(shù)據(jù)還是代碼？

很明顯，Both!說配置是數(shù)據(jù)，因?yàn)樗锹暶魇降拿枋?#xff0c;能方便地修改和傳輸；說配置是代碼，因?yàn)樗诒磉_(dá)邏輯，你的程序?qū)嶋H上就是配置的解釋器。

3) 配置的格式是什么？

配置的格式是任意的，可以自己定義語法，只要配以相應(yīng)的解釋器就行。不過更簡(jiǎn)單通用的做法是基于XML、JSON、或S表達(dá)式等標(biāo)準(zhǔn)結(jié)構(gòu)，在此之上進(jìn)一步定義schema。甚至完全不必是文件，在我們的項(xiàng)目中配置經(jīng)常是放到用關(guān)系數(shù)據(jù)庫中的。另外，下面我們還會(huì)看到用語言的Literal數(shù)據(jù)作為配置。

4) 業(yè)務(wù)邏輯都可以放到配置中嗎？

這個(gè)問題的答案顯然是：Yes！我沒有遇到過不可以放入配置的邏輯，只是問題在于這樣做是否值得，能達(dá)到什么效果。對(duì)于需要靈活變化，重復(fù)出現(xiàn)，有復(fù)用價(jià)值的東西放入作為配置是明智的選擇。這篇文章的主要目的就在于介紹把主要業(yè)務(wù)邏輯都放到配置中，再通過程序解釋執(zhí)行配置的設(shè)計(jì)方法，我稱之為：元驅(qū)動(dòng)編程(Meta Driven Programming)。

轉(zhuǎn)載于:https://www.cnblogs.com/alantu2018/p/8503445.html

總結(jié)

以上是生活随笔為你收集整理的数据即代码：元驱动编程的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。