首選聲明式API設計而不是命令式設計的原因有哪些

這篇文章主要介紹“首選聲明式API設計而不是命令式設計的原因有哪些”，在日常操作中，相信很多人在首選聲明式API設計而不是命令式設計的原因有哪些問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”首選聲明式API設計而不是命令式設計的原因有哪些”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

React是聲明性的。SQL也是聲明性的。有共同點嗎?

> Provided by author

我們現在的許多應用程序周圍的API。例如，我們的應用程序代碼的許多核心通過API通信。我們通過用可理解的抽象分層構建應用程序。此抽象層至關重要，因為它有助于我們解決我們的軟件是如何編寫的及其問題。

定義API的兩種流行方法是命令式和聲明式。SQL是一種聲明性查詢語言，而IMS和CODASYL查詢數據庫則使用命令性代碼。最常用的編程語言是必須的。

但是，在本文中，聲明性API得到更廣泛使用的主要原因之一是，與命令性API相比，聲明性API的使用更加簡潔，并且提供了更好的抽象性。

數據模型中的命令式聲明式

在沒有SQL之前，在1960年，IBM設計了信息管理系統(IMS)，它具有一個稱為CODASYL的分層模型，類似于文檔數據庫中使用的JSON模型。

該模型稱為網絡模型，它有助于為多對多關系創建數據模型。每條記錄將有多個父級，我們將一條記錄相對于另一條記錄進行標記的方式是使用編程語言中的指針而不是外鍵。

> Source: A Codasyl-type Schela Forp Natural La;g’uage Miedical  Records

如果要獲取特定鏈接的值，則必須從列表的頭開始遍歷，一次查看一個記錄，直到找到所需的記錄為止。

這種檢索數據的方式使開發人員很難進行任何更新或更改，因為他們必須跟蹤所有關系和鏈接的父級，否則他們將找不到所需的數據。

關系模型數據查詢有何不同

關系模型使用另一種查詢數據的方式。作為開發人員，我們將告訴程序“做什么”，而不是“怎么做”。因此，查詢優化器將自動決定按哪個順序執行查詢的哪個部分以及使用哪個索引。

“告訴程序“做什么”，而不是“如何”做。”

聲明性方法的一個好處是查詢語言使用API抽象了客戶的實現細節。這可以為優化查詢優化器留出空間，以產生更好的性能并引入更新的功能，而無需任何查詢更改。

隨著越來越多的計算邏輯轉向軟件而非硬件，SQL因其靈活性而變得越來越流行和廣泛使用。

讓我們看一下網絡瀏覽器中的聲明性API和命令性API的另一種類比和說明。

Web服務舉例

讓我們舉一個在Web瀏覽器中使用聲明式和命令式方法處理DOM元素的示例。

通常，使用CSS是聲明性的，而使用JavaScript操作DOM元素則勢在必行。在下面的示例中，您可以看到為什么CSS在Web上查詢數據要比JavaScript更好的原因。

更改HTML標記上“The one who got away”段落中文本的顏色，如下所示：

<ul>   <li class="topClass">     <p> The one who got away </p>     <ul>       <li>article1</li>       <li>article2</li>       <li>article3</li>         </ul>   </li>   <li>     <p> What I learn from my mistakes</p>     <ul>       <li> subArticle </li>       <li> subArticle2 </li>     </ul>   </li> </ul>

使用CSS，您的代碼將如下所示：

li.topClass > p {   color: blue }

比較簡單，因為它聲明了我們要將文本的藍色應用于其中的元素的模式。不在類名topClass下的

標記段不會更改顏色，因為它與聲明不匹配。

另一方面，使用JavaScript來操縱DOM元素將如下所示：

let liElements = document.getElementsByTagName("li"); for(let i = 0; i< liElements.length; i++) {   if(liElements[i].className == "topClass") {     const children = liElements[i].cildNodes;     for(let j = 0; j< children.length; j++) {       if(children[i].nodeType === NODE.ELEMENT_NODE && child.tagName === 'P'){         child.setAttribute('style', 'color:blue');       }     }   } }

使用JavaScript來操作DOM元素，我們必須告訴程序如何做到這一點。它沒有告訴程序我們要達到的目的的抽象概念。該代碼不但比CSS長很多，也很難理解。新手開發人員將需要完全按照HTML頁面的說明進行操作，以了解其功能意圖。

此外，我們必須跟蹤在DOM節點上設置的內容，以及未在DOM節點上放置的內容。例如，如果用戶轉到下一頁，我們需要手動知道如何將color：blue設置回黑色。而且，如果API發生了變化，例如新功能getElementByTagNameV2(我只是在做些事情)，則客戶端將需要重寫該函數，因為API與客戶端的實現緊密相關。

另一方面，以聲明性的方式定義API-我們可以優化瀏覽器性能，而無需客戶端更改他們編寫的任何CSS標記。

我們知道，與在CODASYL中使用SQL相比，在Web瀏覽器中查詢數據比CSS更靈活，更容易向后兼容。

在實踐中

最終，API的抽象度越高，API的聲明性就越高。所有低級API都公開了您要調用的動詞，并且如果沒有命令性API，我們就無法封裝高級抽象API。換句話說，必須存在命令性API才能將API封裝為聲明性API。

如果要使API更具聲明性，請將配置放在API上進行進一步的抽象。通常，聲明性API將通過為您提供一些容錯功能，因此您不必考慮到某些方面。

假設您希望在隊列中創建對輪詢值的抽象。您可以通過提供功能poll()提及輪詢的機制。

以聲明poll()的命令方式，它只會做一件事-poll。如果在此過程中出現網絡問題或故障，它將僅引發異常。

編寫API的一種聲明方式是提及函數意圖的配置。例如，如果您希望重試計數為2，并且在失敗時執行特定操作。客戶端需要解決的任何特定錯誤處理或功能都可以將其封裝在config值中，該值可讓API為您完成所有艱苦的工作。

閉幕

我們將了解為什么聲明式API比命令式API更容易理解和使用。首先，我們了解當前廣泛使用的查詢語言-SQL，以及與前一個CODASYL相比的查詢語言。然后，我們看到查詢網絡瀏覽器的聲明方式如何比命令形式更輕松。最后，了解用戶的意圖并使用配置抽象他們需要實現的所有邏輯是過渡到聲明性API的絕佳方法。

到此，關于“首選聲明式API設計而不是命令式設計的原因有哪些”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！