GUI程序界面設(shè)計(jì)用純C語(yǔ)言怎么做？我們談的是理想，不是現(xiàn)實(shí)。GUI的特點(diǎn)是多變復(fù)雜，需要大量的人力來(lái)完成。所以適合GUI的語(yǔ)言一定是能節(jié)省人力的特性。從編程語(yǔ)言的角度來(lái)說(shuō)，能越快給程序員反饋，語(yǔ)言編

GUI程序界面設(shè)計(jì)用純C語(yǔ)言怎么做？

我們談的是理想，不是現(xiàn)實(shí)。

GUI的特點(diǎn)是多變復(fù)雜，需要大量的人力來(lái)完成。所以適合GUI的語(yǔ)言一定是能節(jié)省人力的特性。從編程語(yǔ)言的角度來(lái)說(shuō)，能越快給程序員反饋，語(yǔ)言編寫(xiě)越接近最終產(chǎn)品的用戶界面越好。

0.寫(xiě)作很簡(jiǎn)單。語(yǔ)法簡(jiǎn)單，噪音少，不用寫(xiě)樣板。支持功能封閉是基礎(chǔ)。Kotlin中的UI DSL和括號(hào)實(shí)際上并不是特別干凈，所以它 最好像CoffeeScript那樣用縮進(jìn)來(lái)表達(dá)。

跟蹤垃圾收集.這個(gè)寫(xiě)起來(lái)也簡(jiǎn)單。比如C/C /Rust就不適合寫(xiě)GUI。GUI編程中要搞清楚一個(gè)視圖的生命周期或者所有權(quán)太難了，就算明天界面變了也是錯(cuò)的。偶數(shù)objC s refcount感覺(jué)有點(diǎn)麻煩。

類型系統(tǒng)是靈活的。GUI編程例程太復(fù)雜，并且整天都在變化。最好是結(jié)構(gòu)型的，像GoLang或者TypeScript。最好是臨時(shí)定義一個(gè)類型或者類似JSON的對(duì)象來(lái)傳播。

能夠反映視圖的DSL。能夠通過(guò)查看代碼的視覺(jué)形狀來(lái)想象GUI表單是增加效率的重要手段，用過(guò)程化的創(chuàng)建UI過(guò)于繁瑣和直觀。事實(shí)上，不僅可視化組件可以對(duì)應(yīng)DSL，組件上的事件處理(如點(diǎn)擊處理程序)和樣式也可以直接寫(xiě)在DSL上。除了直觀的好處，還可以用邏輯代碼動(dòng)態(tài)創(chuàng)建視圖，寫(xiě)模板(XML/HTML)稍微麻煩一點(diǎn)。

能夠快速響應(yīng)代碼變更。參考webpack的熱模塊重裝和flutter的熱重裝。上面說(shuō)了UI需要大量的人力，調(diào)整細(xì)節(jié)就是其中之一。熱重裝是加速GUI語(yǔ)言開(kāi)發(fā)，減少人力的最大武器。

語(yǔ)言伴隨著異步編程而來(lái)。UI編程中有很多場(chǎng)景需要等待用戶輸入/資源請(qǐng)求。語(yǔ)言層面的異步編程非常重要。比如async/await的語(yǔ)法就是一種支持，或者Rx作為標(biāo)準(zhǔn)庫(kù)也是一種支持。Golang s CSP異步模型不適合UI編程，或者過(guò)于冗長(zhǎng)直觀。如何支持異步編程還沒(méi)有想透，但是用GUI語(yǔ)言進(jìn)行異步編程肯定是必須的。

簡(jiǎn)而言之，就是如何寫(xiě)得又快又好。如果結(jié)合以上幾點(diǎn)，最好的GUI語(yǔ)言是

CoffeeScript類型腳本類型系統(tǒng)的語(yǔ)法/await/Rx

如何做一個(gè)api接口？

我們知道，API實(shí)際上是一個(gè)應(yīng)用程序編程接口，可以理解為與不同軟件系統(tǒng)溝通的通道。本質(zhì)上，它是一個(gè)預(yù)定義的函數(shù)。API有很多種形式，最常見(jiàn)的是用HTTP協(xié)議提供服務(wù)(比如RESTful)，只要符合規(guī)范就可以正常使用。現(xiàn)在各類企業(yè)在信息化中都會(huì)用到第三方提供的API，也會(huì)提供API給第三方調(diào)用，所以設(shè)計(jì)API也需要謹(jǐn)慎。

如何開(kāi)發(fā)設(shè)計(jì)一個(gè)好的API接口？

定義功能在設(shè)計(jì)之初，就要對(duì)API的詳細(xì)功能進(jìn)行梳理，并按業(yè)務(wù)功能點(diǎn)或模塊進(jìn)行劃分，從而明確API需要提供哪些功能。

清晰的代碼邏輯保持代碼整潔，添加必要的注釋，界面保證功能單一。如果一個(gè)接口需要復(fù)雜的業(yè)務(wù)邏輯，建議拆分成多個(gè)接口或者將功能獨(dú)立打包成公共方法，避免接口中代碼過(guò)多，不利于后期人員維護(hù)和后期迭代。

必要的安全檢查機(jī)制目前Web應(yīng)用容易出現(xiàn)數(shù)據(jù)、篡改、非法提交、重復(fù)請(qǐng)求等安全問(wèn)題，API的安全檢查機(jī)制必不可少。常見(jiàn)的解決方案是采用數(shù)字簽名的形式，給每個(gè)HTTP請(qǐng)求添加一個(gè)簽名，服務(wù)器端驗(yàn)證簽名的合法性，保證請(qǐng)求的合法性。

日志記錄為了及時(shí)定位問(wèn)題，日志是必不可少的。

一個(gè)好的降低耦合度的API應(yīng)該盡可能簡(jiǎn)單。如果API之間的業(yè)務(wù)耦合度過(guò)高，很容易出現(xiàn)代碼異常導(dǎo)致相關(guān)API不可用，從而盡可能避免API之間復(fù)雜的調(diào)用關(guān)系。

返回有意義的狀態(tài)碼API返回?cái)?shù)據(jù)應(yīng)該攜帶狀態(tài)碼數(shù)據(jù)，比如200表示正常請(qǐng)求，500表示內(nèi)部。返回公共狀態(tài)代碼有利于問(wèn)題定位。例如，您可以參考以下?tīng)顟B(tài)代碼:

開(kāi)發(fā)文檔既然API是提供給第三方或者內(nèi)部使用的，那么開(kāi)發(fā)文檔是必不可少的，否則別人就不知道怎么調(diào)用了。一個(gè)好的API開(kāi)發(fā)文檔應(yīng)該包括以下元素:

1.環(huán)境信息，如當(dāng)前API架構(gòu)模式說(shuō)明、開(kāi)發(fā)工具和版本、系統(tǒng)閑置等；

2.當(dāng)前的API提供了哪些功能？

3.API模塊之間的惰性關(guān)系；

4.通話規(guī)則和注意事項(xiàng)；

5、部署注意事項(xiàng)等。

一個(gè)好的API一定要易用、易懂、易擴(kuò)展、不易誤用、安全性高、功能強(qiáng)大。做到以上并不容易，但要遵循以上原則，結(jié)合業(yè)務(wù)本身的合理劃分來(lái)設(shè)計(jì)API。

那個(gè) 這是我的看法。你怎么看待這個(gè)問(wèn)題？歡迎在下方評(píng)論區(qū)交流~我是科技領(lǐng)域的創(chuàng)作者，有十年互聯(lián)網(wǎng)行業(yè)經(jīng)驗(yàn)。歡迎關(guān)注我了解更多科技知識(shí)！