什么是API

API（Application Programming Interface）提供了對某個問題的抽象，以及客戶與解決該問題的軟件組件之間進行交互的方式。組件本身通常以軟件類庫形式分發(fā)，它們可以在多個應(yīng)用 程序中使用。概括地說，API定義了一些可復(fù)用的模塊，使得各個模塊化功能塊可以嵌入到終端用戶的應(yīng)用程序中去。

你可以為自己、你所在機構(gòu)中的其他工程師或大型開發(fā)社區(qū)編寫API。它可以小到只包含一個單獨的函數(shù)，也可以大到包含數(shù)以百計的類、方法、全局函 數(shù)、數(shù)據(jù)類型、枚舉類型和常量等。它的實現(xiàn)可以是私有的，也可以是開源的。有關(guān)API的一個重要的基本定義是：API是一個明確定義的接口，可以為其他軟 件提供特定服務(wù)。

現(xiàn)代應(yīng)用程序通常都是基于很多API建立起來的，而這些API往往又依賴于其他API。如圖1-1中示例應(yīng)用程序所示，該應(yīng)用程序用到了3個類庫 （1、2、3）的API，而這3個API中有2個又用到了另兩個類庫（4和5）。舉例來說，瀏覽圖片的應(yīng)用程序可能會用到加載GIF圖片的API，而該 API本身則可能又依賴更底層的壓縮或解壓縮數(shù)據(jù)的API。

圖字翻譯：

 Application Code：應(yīng)用程序代碼

 Library：類庫

圖1-1 從層次化API中調(diào)用例程的應(yīng)用程序。每個方框代表一個軟件類庫，灰色部分表示其公共接口，對于類庫而言即是其API，白色部分表示隱藏在API后面的具體實現(xiàn)。

API開發(fā)在現(xiàn)代軟件開發(fā)中隨處可見，其目的是為某個組件的功能提供一個邏輯接口，同時隱藏該模塊內(nèi)部的實現(xiàn)細節(jié)。舉例來說，我們用來讀取GIF圖片的API可能僅僅提供一個LoadImage()方法，后者接收一個文件名作為參數(shù)，并返回一個2維的像素數(shù)組。所有文件格式和數(shù)據(jù)壓縮的細節(jié)全部隱藏在這個看似簡單的接口之下。這個概念也在圖1-1中進行了說明，即客戶端代碼只能夠通過該API的公有接口訪問。API公有接口如圖1-1中每個方框頂部的灰色區(qū)域所示。

為什么選用C++來描述API設(shè)計

雖然有很多通用API設(shè)計方法學(xué)（可適用于任何編程語言或編程環(huán)境）可以講，但最終都需要使用一門特定的編程語言來表述。因此了解特定語言的特征以 促進規(guī)范的API設(shè)計是非常必要的。所以，本書專門使用一種語言（C++）描述API設(shè)計的問題，而非分散內(nèi)容使其適用于所有語言。然而，想要使用其他語 言（如Java或C#）開發(fā)API的讀者仍然可以從本書中獲得許多通用的深刻見解。本書的直接目標讀者是編寫并維護API的C++工程師，他們的API要 供給其他工程師使用。

目前，C++仍是大型軟件項目中使用最廣泛的編程語言之一，并且日漸成為注重代碼性能項目的***語言，因此，你可以在自己應(yīng)用中選用的C和C++的 API種類非常多（前面我已經(jīng)列出一些）。本書重點關(guān)注如何使用C++編寫優(yōu)秀API，并引入了豐富的源代碼示例以更好地闡述這些概念。也就是說，本書會 涉及一些C++特有的主題，例如模板、封裝、繼承、命名空間、操作符、const正確性、內(nèi)存管理、STL的使用、Pimpl慣用法，等等。

另外，在本書出版期間，C++也正經(jīng)歷著巨大的變革。新版的C++規(guī)范處于ISO/IEC的標準化進程中。目前，多數(shù)C++編譯器遵循1998年***發(fā)布的標準，即C++98。隨后的標準于2003年出版，修正了前版的幾處缺陷。自那時以來，標準委員會一直致力于一個重大的新版本規(guī)范。在標準被正式 批準生效并確定發(fā)布日期之前，該版本一直被非正式地稱為C++0x。當你讀到本書時，新的標準可能已經(jīng)發(fā)布了。但是，在我編寫本書的期間，它仍然被稱為 C++0x。

盡管如此，C++0x已經(jīng)達到標準化進程的高級階段，我們可以滿懷信心地預(yù)言一些新的特性。事實上，一些主流的C++編譯器已經(jīng)開始實現(xiàn)許多建議的 新特性。在API設(shè)計方面，某些新特性可以用來構(gòu)建更加優(yōu)雅和健壯的接口。因此，我一直努力在整本書中強調(diào)和解釋C++0x中的API設(shè)計。所以，本書在 未來幾年中應(yīng)該依然具有參考價值。

為什么使用API

在軟件項目中為什么要關(guān)注API，這一問題可以從兩個方面理解：(1)為什么要設(shè)計并編寫API？(2)為什么要在應(yīng)用中使用其他人提供的API？我將在接下來的小節(jié)中回答這兩個方面的問題，并指出在項目中使用API的各種好處。

如果你正在編寫供其他開發(fā)人員使用的模塊，不管他們是公司里的其他工程師還是外部客戶，比較明智的辦法是構(gòu)建API來讓他們訪問這些功能。這么做會帶來以下好處。

更健壯的代碼

• 隱藏實現(xiàn)。通過隱藏模塊內(nèi)部實現(xiàn)的細節(jié)，開發(fā)人員就可以在未來的某個時間自由修改模塊的實現(xiàn)而不給用戶造成重 大影響。如若不然，會導(dǎo)致以下結(jié)果：（1）代碼的更新將會受到限制；（2）用戶只有重寫代碼才能使用新版本的程序庫。如果總是讓用戶不停地更新軟件版本， 他們很可能不愿再做更新，或者干脆棄用，另外尋找不需要太多維護工作的API。因此，優(yōu)秀的API設(shè)計對業(yè)務(wù)或項目成功至關(guān)重要。
• 延長壽命。隨著使用時間增長，那些公開了實現(xiàn)細節(jié)的系統(tǒng)的內(nèi)部代碼會變得錯綜復(fù)雜，系統(tǒng)的各個部分要依賴其他 部分的內(nèi)部實現(xiàn)細節(jié)。因此，系統(tǒng)將會變得脆弱、死板、不可移植且粘滯性高（Martin，2000）。如此一來，公司為了改善這些代碼，就不得不花費大量 人力財力，甚至推倒重寫。事先花工夫做好API設(shè)計，而后維護好該設(shè)計以保證一致性，軟件壽命就能延長，從長遠看也能節(jié)省花費。在第4章的前面部分，我們 會深入討論該問題。
• 促進模塊化。API通常用來完成一項具體的任務(wù)或用例。因此，API定義了一組具有一致目的的模塊化的功能集。在大量API基礎(chǔ)之上開發(fā)的應(yīng)用，其結(jié)構(gòu)將降低耦合而更加模塊化，每一個模塊的行為都不依賴其他模塊的內(nèi)部細節(jié)。
• 減少代碼重復(fù)。代碼重復(fù)是軟件工程中最惡劣的行為之一，任何時候都要避免犯此類錯誤。通過把所有的代碼邏輯置 于一個嚴格的接口之后，讓所有客戶使用這個接口，就能將程序的某種行為統(tǒng)一處理。這樣做意味著只需更新一處代碼就可以改變向所有客戶提供的API的行為。 這樣有助于消除代碼中所有重復(fù)的實現(xiàn)。事實上很多的API就是這樣實現(xiàn)的，人們首先發(fā)現(xiàn)有重復(fù)的代碼，然后制作統(tǒng)一的接口取代這些重復(fù)代碼，于是就產(chǎn)生了 API。這是一件好事。
• 消除硬編碼負擔。很多程序可能包含硬編碼的值，并在整個代碼中不斷復(fù)制。例如，在需要寫日志文件的地方就使用具體的文件名“myprogram.log”。我們可以使用API來提供這些信息，而不用在整個代碼層面復(fù)制這些常量，例如，使用GetLogFilename() API調(diào)用代替硬編碼的“myprogram.log”字符串。
• 易于改變實現(xiàn)。如果將所有的實現(xiàn)細節(jié)隱藏在公共接口背后，就可以在不影響任何依賴此API代碼的情況下改變其內(nèi)部的實現(xiàn)細節(jié)。例如，可以將原本使用std::string解析文件的方式變?yōu)榉峙?、釋放、再分?code>char*緩沖區(qū)的方式。
• 易于優(yōu)化。成功隱藏了實現(xiàn)細節(jié)后，在優(yōu)化API的性能時就不用操心更改客戶端代碼。例如，可以利用加設(shè)緩存的方案優(yōu)化某個計算密集型的方法。之所以這樣做是因為所有讀寫潛在數(shù)據(jù)的操作都是通過該API進行的，因此該API更確切地知道何時緩存中的結(jié)果無效并且需要重新計算結(jié)果。

#p#

代碼重用

代碼重用就是使用已有的軟件去構(gòu)建新的軟件。這是現(xiàn)代軟件開發(fā)所追求的一個神圣的目標。API提供了一種代碼復(fù)用的機制。

在早期的軟件開發(fā)中，有種情況很常見，即公司不得不為其制作的任一應(yīng)用編寫所有代碼。如果某個程序需要讀取GIF圖片或者解析文本文件，公司不得不 自己編寫全部代碼。如今，隨著優(yōu)秀的商業(yè)庫和開源庫的增多，重用別人已經(jīng)編寫過的代碼變得非常簡單。舉例來說，如今已經(jīng)有各種開源的讀取圖像的API和解 析XML的API供人們下載和使用。這些庫被世界上許多程序開發(fā)人員不斷地改進和調(diào)試，同時也已經(jīng)在很多其他程序中被實踐檢驗過。

通過使用不同的組件（它們用于構(gòu)建應(yīng)用程序各個模塊）并借助組件已發(fā)布的API相互通信，軟件開發(fā)從本質(zhì)上已變得更加模塊化。這種做法的好處是不需 要了解每個軟件組件的所有細節(jié)，如同前面提到的建造房屋的比喻，可以將很多細節(jié)問題委托給專業(yè)承包商。這樣能夠縮減開發(fā)周期，這一方面是因為可以重用已有 的代碼，另一方面則因為可以將各種組件的開發(fā)計劃分離，還可以讓開發(fā)者把重點放在核心業(yè)務(wù)邏輯上，而不必浪費時間重新發(fā)明輪子。

然而，實現(xiàn)代碼重用的一個障礙是，常常需要比原本計劃更加通用的接口，因為其他客戶可能有額外的期望和需求。因此有效的代碼重用來自對軟件客戶的深入了解以及結(jié)合了客戶和自身利益的系統(tǒng)設(shè)計。

C++ API和WEB

依賴第三方API的應(yīng)用程序在云計算領(lǐng)域里越來越普遍。該領(lǐng)域中，Web應(yīng)用越來越依賴Web服務(wù)（API）為其提供核心功能。對于Web混搭應(yīng)用程序 （mashup），應(yīng)用程序本身有時僅僅是對多種已有服務(wù)進行再次封裝，從而提供新的服務(wù)。例如，將Google地圖API和本地犯罪統(tǒng)計數(shù)據(jù)庫相結(jié)合就 可以為犯罪數(shù)據(jù)提供一個基于地圖的界面。

實際上，花一些時間強調(diào)C++ API設(shè)計在Web開發(fā)中的重要性是值得的。膚淺的分析可能得出這樣的結(jié)論：服務(wù)器端的Web開發(fā)局限于腳本語言，諸如PHP、Perl、 Python（即流行的LAMP架構(gòu)縮寫中的“P”），或者基于Microsoft ASP（動態(tài)服務(wù)器頁面）技術(shù)的.Net語言。對于小規(guī)模的Web開發(fā)可能確實如此，然而值得注意的是，許多大規(guī)模的Web服務(wù)器都使用C++實現(xiàn)的后臺 服務(wù)，以求***性能。

事實上，F(xiàn)acebook開發(fā)過一個名為HipHop的產(chǎn)品，它將PHP代碼轉(zhuǎn)換為C++，以此改善社交網(wǎng)站的性能。因此C++ API設(shè)計在可擴展的Web服務(wù)開發(fā)中確實占有一席之地。此外，使用C++開發(fā)核心API不僅可以構(gòu)建高性能的Web服務(wù)，而且這些代碼還可以在諸如桌面 或移動電話版本等其他形式交付的產(chǎn)品中重用。

說句題外話，對于這種軟件開發(fā)策略的轉(zhuǎn)變，一種可能的解釋是全球化推動的結(jié)果（Friedman，2008；Wolf， 2004）。實際上，互聯(lián)網(wǎng)、標準網(wǎng)絡(luò)協(xié)議和Web技術(shù)的匯聚已經(jīng)創(chuàng)造了一個軟件競技平臺。這使得來自世界各地的公司和個人都可以在大型復(fù)雜軟件項目中進 行創(chuàng)造、貢獻和競爭。這種形式的全球化促成了一種環(huán)境，在該環(huán)境下，全世界的公司和開發(fā)者能夠以開發(fā)軟件子系統(tǒng)為生。世界各地的其他組織進而可以通過組合 與擴展這些構(gòu)建模塊創(chuàng)建解決特定問題的最終用戶應(yīng)用程序。就本書討論的焦點而言，API提供了促成現(xiàn)代軟件開發(fā)全球化和組件化的機制。

并行開發(fā)

即使你只是編寫內(nèi)部軟件，與你共事的工程師也很可能要使用你的代碼編輯程序。如果使用良好的API設(shè)計技巧，就可以簡化彼此的工作，不必回答諸多關(guān)于代碼如何工作、如何使用的問題。這在多個開發(fā)者并行開發(fā)相互依賴的代碼時顯得尤為重要。

舉例來說，假設(shè)你正在編寫一個字符串加密算法，其他開發(fā)者需要使用該算法將數(shù)據(jù)寫入配置文件。一種做法是讓其他開發(fā)者等你完成所有工作，然后在其文 件輸出模塊中使用你的算法。然而，更有效率的做法是，你們提前見面協(xié)商好恰當?shù)腁PI，然后你把API放在適當?shù)奈恢?，而API僅僅起占位符的作用，這樣 你的同事就可以立即調(diào)用它們了，例如：

#include <string>  
 
classStringEncryptor 
{ 
public: 
    ///設(shè)置Encrypt()和Decrypt()調(diào)用時使用的密鑰 
    voidSetKey(conststd::string &key); 
 
    ///基于當前密鑰加密輸入字符串 
    std::string Encrypt(conststd::string &str) const; 
 
    ///基于當前密鑰解密輸入字符串 
    /// Decrypt()一個由Encrypt()返回的字符串 
    /// 返回同一個密鑰下原始的字符串 
    std::string Decrypt(conststd::string &str) const; 
}; 

接著，你可以提供這些函數(shù)的簡單實現(xiàn)，使得該模塊至少可以編譯和鏈接。例如，相關(guān)的.cpp文件可以像下面這樣：

voidStringEncryptor::SetKey(conststd::string &key) 
{ 
} 
std::string StringEncryptor::Encrypt(conststd::string &str) 
{ 
    return str; 
} 
std::string StringEncryptor::Decrypt(conststd::string &str) 
{ 
    return str; 
} 



#p#

這樣一來，你的同事就能夠使用這個API繼續(xù)工作而不被你的進度所耽擱。雖然目前你的API實際上不會加密任何字符串，但是這只是一個小的實現(xiàn)細節(jié)。重要的是已經(jīng)有了一個雙方都認可的穩(wěn)定接口，即一個契約，而且該接口的行為恰當，例如Decrypt(Encrypt("Hello"))將會返回“Hello”。當你完成了工作，并以正確的實現(xiàn)更新了.cpp文件后，你同事的那部分代碼不需要進行任何修改就能直接運行了。

實際上，有些接口問題很可能在編寫代碼之前并沒有預(yù)料到，因此API設(shè)計可能需要多次迭代才能保證其恰到好處。在大多數(shù)情況下，API支持雙方能夠以最少的停頓并行工作。

這種方法還用利于測試驅(qū)動或者是測試先行的開發(fā)。事先確定了API，就可以編寫單元測試來驗證預(yù)期的功能，并且可以持續(xù)運行這些測試程序，以保證始終沒有打破你和同事之間的協(xié)議。

將該過程延伸到組織層面，你的項目可以有獨立的團隊，他們彼此也許相距很遠，甚至遵循不同的日程安排。通過預(yù)先確定各個團隊的依賴關(guān)系，并通過創(chuàng)建 API來為這些關(guān)系建模，各個團隊就可以獨立工作，而幾乎不必關(guān)心其他團隊如何實現(xiàn)API背后的工作。資源的有效利用以及削減相應(yīng)的冗余通信，能夠為組織 節(jié)約大量整體成本。

何時應(yīng)當避免使用API

設(shè)計并實現(xiàn)API相比編寫普通的應(yīng)用程序代碼通常要花費更多精力，因為API的宗旨是提供健壯、穩(wěn)定的接口供其他開發(fā)人員使用。因此，與僅在單一應(yīng)用程序內(nèi)部使用的軟件相比，API在質(zhì)量、設(shè)計、文檔編寫、測試、支持及維護方面有更高的要求。

因此，如果編寫的是不需要和其他客戶端通信的內(nèi)部模塊，那么為模塊創(chuàng)建并維護穩(wěn)定公有接口的額外開銷就不值得了，然而這并不是編寫劣質(zhì)代碼的理由。為堅持API設(shè)計原則而多花費些時間，從長遠看來并不浪費時間和精力。

另一方面，假設(shè)你是一位想在應(yīng)用程序中使用第三方API的軟件開發(fā)人員。前一節(jié)討論了在軟件中重用外部API的一些理由，但有時也可能需要避免使用特定的API，在如下這些情況下，你應(yīng)該花精力自己實現(xiàn)代碼或?qū)ふ姨娲慕鉀Q方案。

• 許可證限制。雖然API可以提供所需的各項精巧功能，但是許可證限制可能讓你望而卻步。例如，如果你想使用 GNU GPL（General Public License，通用公共許可證）發(fā)布的開源包，那么就必須使用GPL發(fā)布所有衍生作品。如果在程序中使用這個包，就必須發(fā)布整個應(yīng)用程序的源代碼，這是 商業(yè)應(yīng)用可能不會接受的約束。其他的許可證（如GNU Lesser General License GPL，LGPL）就更加寬松些，在軟件庫中也更加常見。許可證問題的另一種體現(xiàn)是：商業(yè)API的費用對你的項目來說可能過于昂貴，或者許可條款可能過于 嚴格，比如要求向每位開發(fā)者甚至每位用戶收取許可費用。
• 功能不匹配。雖然API看似能夠解決所面臨的問題，但是它有可能以一種與應(yīng)用程序約束或功能需求不匹配的方式 執(zhí)行。例如，可能你正在開發(fā)一個圖像處理工具，想要提供傅里葉變換功能。雖然有許多現(xiàn)成的FFT（Fast Fourier Transform，快速傅里葉變換）的實現(xiàn)，但是其中大多數(shù)是1D算法，而處理2D圖像數(shù)據(jù)需要使用2D FFT。此外，許多2D FFT算法只能在大小是2的整數(shù)冪的數(shù)據(jù)集上工作（如256×256或512 × 512）。或許你找到的API不能在必須支持的平臺上運行，或者它不能滿足你對程序制定的性能標準。
• 缺少源代碼。雖然有許多開源API，但是有時符合要求的***API可能是閉源產(chǎn)品。也就是說，只提供接口的頭 文件，而背后的C++源文件并不同庫一起發(fā)布。這有幾項重要的影響，其中之一就是當庫中存在錯誤時，不能通過檢查源代碼的方式定位問題。對于跟蹤錯誤進而 找到解決方案來說，閱讀源代碼是一個很重要的方法。
• 進一步說，不能訪問API的源代碼就喪失了通過修改源代碼修復(fù)錯誤的能力。這意味著軟件項目的進度可能會受到所使用的第三方API中不可預(yù)期問題的不利影響，并且需要等待該API的所有者處理你的錯誤報告并發(fā)布修復(fù)補丁。
• 缺乏文檔。雖然API看似可以完全滿足應(yīng)用程序的需求，但是如果API的文檔編寫拙劣或根本沒有文檔，那么你 ***再去尋找別的解決方案。在這種情況下，有可能是API的用法不清楚影響了它的使用，也有可能是你無法確定特定情況下API的行為，甚至可能是你根本 無法信任那些連花點兒時間解釋代碼都做不到的開發(fā)者。

原文鏈接：http://www.ituring.com.cn/article/50227