專利名稱：應(yīng)用編程接口(api)的設(shè)計(jì)的制作方法
技術(shù)領(lǐng)域：
本發(fā)明一般涉及應(yīng)用編程接口(API)，尤其涉及，作為示例而非局限，設(shè)計(jì)易于使用的API而同時(shí)提供控制和靈活性。
背景技術(shù)：
應(yīng)用編程接口(API)由開發(fā)者用于創(chuàng)建各種各樣的應(yīng)用和程序。開發(fā)者的范圍從記錄宏的辦公室工作人員到低層設(shè)備驅(qū)動(dòng)器作者。這些開發(fā)者依靠具有不同復(fù)雜度的不同語(yǔ)言和/或不同框架，而使用不同的技能組和/或?yàn)椴煌哪康膩?lái)編程。傳統(tǒng)地，設(shè)計(jì)了不同的API以不同的個(gè)別技能級(jí)別和對(duì)控制的不同需求(如基于不同的相關(guān)場(chǎng)景)為目標(biāo)。
盡管該方法能夠成功地提供為具體的開發(fā)者優(yōu)化的API，它仍具有顯著的不足。例如，多框架方法產(chǎn)生了開發(fā)者很難將知識(shí)從一個(gè)技能級(jí)別和場(chǎng)景類型轉(zhuǎn)移到另一個(gè)的情況。當(dāng)他們需要使用不同的框架實(shí)現(xiàn)場(chǎng)景時(shí)，開發(fā)者遭遇陡峭的(steep)學(xué)習(xí)曲線。并且不僅學(xué)習(xí)曲線極陡峭，而且它一般需要寫入第一較低技能級(jí)別框架的代碼必須被從無(wú)到有地寫入第二較低技能級(jí)別框架中。此外，為不同的開發(fā)者技能級(jí)別創(chuàng)建單獨(dú)的框架通常導(dǎo)致以一個(gè)級(jí)別開發(fā)者為目標(biāo)或由其實(shí)現(xiàn)的API無(wú)法由另一級(jí)別開發(fā)者使用的情況。
圖1示出了關(guān)于兩種不同框架的傳統(tǒng)API學(xué)習(xí)曲線的曲線圖101。第一框架對(duì)應(yīng)于具有相對(duì)較低級(jí)別的技能和/或難度要求同時(shí)伴之以由開發(fā)者控制的容量相對(duì)較低的框架。另一方面，第二框架對(duì)應(yīng)于具有相對(duì)較高級(jí)別的所需要的技能和/或難度以及伴隨的用于由開發(fā)者控制的相對(duì)較高容量的框架。這樣的第一框架可由新手或偶爾為之的開發(fā)者使用，并且這樣的第二框架可由有經(jīng)驗(yàn)的或?qū)I(yè)開發(fā)者使用。例如，第一框架可對(duì)應(yīng)于為Visual Basic所設(shè)計(jì)的框架，而第二框架可對(duì)應(yīng)于為C++所設(shè)計(jì)的框架。
在該傳統(tǒng)方法中，設(shè)計(jì)并采用了相對(duì)分離且全異的API作為每一框架的一部分?？缭蕉盖偷鄬?duì)較短的學(xué)習(xí)曲線來(lái)啟用為相對(duì)較低技能級(jí)別和控制能力的第一框架的API使用。由于兩個(gè)API框架的分離和全異特性，對(duì)第一框架的經(jīng)驗(yàn)對(duì)于學(xué)習(xí)第二框架的第二API所貢獻(xiàn)的知識(shí)很少，如果說(shuō)有的話。因此，要跨越同樣陡峭、甚至更高的學(xué)習(xí)曲線來(lái)啟動(dòng)第二框架的API的使用。
換言之，學(xué)習(xí)第一框架的API不能提供學(xué)習(xí)第二框架的API的墊腳石。這一脫節(jié)的API框架組的退步特性由連續(xù)性間隙指示。學(xué)習(xí)了第一框架的API的開發(fā)者并不能更便捷地學(xué)習(xí)第二框架的API，并且因此必須從第二框架的基礎(chǔ)開始。
傳統(tǒng)框架的另一問題是它們往往在任一情況下都具有總體較差的可用性。一般而言，“優(yōu)化”面向?qū)ο笤O(shè)計(jì)/開發(fā)(OOD)方法(如，統(tǒng)一模型化語(yǔ)言(UML))是為了所得設(shè)計(jì)的可維護(hù)性，而不是所得框架的可用性。OOD方法更適合內(nèi)部結(jié)構(gòu)設(shè)計(jì)，但較不適合大型可重復(fù)使用庫(kù)的API層的設(shè)計(jì)。例如，較差的可用性可根源于OOD方法僅關(guān)注在對(duì)較低功能塊的提煉和/或貫穿整個(gè)API設(shè)計(jì)對(duì)嚴(yán)格的繼承層次具有不動(dòng)搖的忠誠(chéng)度。
因此，需要能夠至少改進(jìn)傳統(tǒng)API學(xué)習(xí)曲線的倒退連續(xù)性間隙和/或能夠供應(yīng)較好的整體API可用性的模式和/或技術(shù)。

發(fā)明內(nèi)容
在第一示例性方法實(shí)現(xiàn)中，用于設(shè)計(jì)應(yīng)用編程接口(API)的方法包括為核心場(chǎng)景準(zhǔn)備多個(gè)代碼樣本，多個(gè)代碼樣本的每一相應(yīng)的代碼樣本對(duì)應(yīng)于多個(gè)編程語(yǔ)言的相應(yīng)的編程語(yǔ)言；以及響應(yīng)于多個(gè)代碼樣本從核心場(chǎng)景衍生API。在第二示例性方法實(shí)現(xiàn)中，用于設(shè)計(jì)API的方法包括為一特征區(qū)域選擇核心場(chǎng)景；為該核心場(chǎng)景書寫至少一個(gè)代碼樣本；以及響應(yīng)于至少一個(gè)代碼樣本為核心場(chǎng)景衍生API。在第三示例性方法實(shí)現(xiàn)中，用于設(shè)計(jì)API的方法包括響應(yīng)于相對(duì)一場(chǎng)景書寫的至少一個(gè)代碼樣本，為該場(chǎng)景衍生API；使用多個(gè)開發(fā)者在該API上執(zhí)行一個(gè)或多個(gè)可用學(xué)習(xí)；以及基于該一個(gè)或多個(gè)可用學(xué)習(xí)修正該API。
本發(fā)明描述了其它方法、系統(tǒng)、途徑、裝置、設(shè)備、媒體、API、過(guò)程、排列等實(shí)現(xiàn)。


貫穿附圖，使用相同的標(biāo)號(hào)標(biāo)識(shí)相同和/或?qū)?yīng)的方面、特征和組件。
圖1示出了關(guān)于兩個(gè)不同框架的傳統(tǒng)API學(xué)習(xí)曲線的曲線圖。
圖2示出了關(guān)于兩個(gè)級(jí)別的抽象的示例性有漸進(jìn)API學(xué)習(xí)曲線的曲線圖。
圖3示出了API的示例性設(shè)計(jì)原理和實(shí)踐。
圖4所示是用于每特征區(qū)域設(shè)計(jì)API的示例性技術(shù)的流程圖。
圖5所示是用于每核心場(chǎng)景設(shè)計(jì)API的示例性模式的框圖。
圖6示出了以兩個(gè)不同的目的為目標(biāo)的示例性組件類型之間的潛在不一致性。
圖7示出了被設(shè)計(jì)成可擴(kuò)充和/或能共同操作以覆蓋兩個(gè)不同目的的組件類型之間的示例性關(guān)系。
圖8示出了用于處理兩層API的兩個(gè)不同目的的示例性聚集組件(AC)和關(guān)聯(lián)的分解類型(FT)。
圖9示出了支持創(chuàng)建—設(shè)置—調(diào)用用法模式的示例性聚集組件和關(guān)聯(lián)的API。
圖10示出了能夠(全部或部分地)實(shí)現(xiàn)設(shè)計(jì)和/或使用本發(fā)明描述的API的至少一個(gè)方面的示例性計(jì)算(或一般設(shè)備)操作環(huán)境。
具體實(shí)施例方式
圖2示出了關(guān)于兩個(gè)不同的抽象級(jí)別的示例性漸進(jìn)API學(xué)習(xí)曲線的曲線圖200。所示的兩個(gè)不同級(jí)別的抽象一個(gè)是相對(duì)高度抽象，一個(gè)是相對(duì)低度抽象。該高度抽象對(duì)應(yīng)于其涉及所需技能和/或難度級(jí)別相對(duì)較低、且伴之以由開發(fā)者控制的容量相對(duì)較低的開發(fā)環(huán)境。另一方面，低度抽象對(duì)應(yīng)于其涉及所需技能和/或難度級(jí)別相對(duì)較高、且伴之以由開發(fā)者控制的容量相對(duì)較高的開發(fā)環(huán)境。
示出漸進(jìn)API學(xué)習(xí)曲線以相對(duì)平滑的方式從較低的需要技能和伴隨的控制能力的一點(diǎn)處升起，通過(guò)高級(jí)和低度抽象的區(qū)域，到較高的需要技能和伴隨的控制能力的一點(diǎn)。漸進(jìn)API學(xué)習(xí)曲線呈現(xiàn)出高度抽象和低度抽象之間的連續(xù)區(qū)。一種集成的API框架可啟用漸進(jìn)的學(xué)習(xí)曲線。由于該API框架的集成特性，對(duì)高度抽象的經(jīng)驗(yàn)向低度抽象以及需要更大控制的場(chǎng)景進(jìn)行的API使用學(xué)習(xí)貢獻(xiàn)了知識(shí)。
換言之，學(xué)習(xí)用于高度抽象的API向?qū)W習(xí)API和/或?qū)PI擴(kuò)充到低度抽象中提供了墊腳石。這由包含高度和低度抽象區(qū)域的兩層API框架形狀指示。如后文所描述的，某些API的漸進(jìn)特性令開發(fā)者能夠最初使用簡(jiǎn)單的API，然后漸進(jìn)地(并部分地)開始使用更復(fù)雜的API組件。由此，學(xué)習(xí)了以高度抽象為目標(biāo)的API的開發(fā)者能夠在其經(jīng)驗(yàn)提供了某種保證和/或當(dāng)他們所面對(duì)的場(chǎng)景的復(fù)雜度提出需要時(shí)轉(zhuǎn)而使用以低度抽象為目標(biāo)的API。
漸進(jìn)API可以是易于使用(尤其在早期學(xué)習(xí)階段)并且高度功能強(qiáng)大的(尤其是當(dāng)隨時(shí)間推移研究API時(shí))?？墒褂玫腁PI可包括以下示例性屬性的一個(gè)或多個(gè)起步時(shí)需要少量概念和/或類、幾行代碼可實(shí)現(xiàn)簡(jiǎn)單的場(chǎng)景、類/方法具有直觀的名字、自然的和/或明顯的起點(diǎn)是顯而易見的、并且有到另外需要的和/或相關(guān)的概念/類的清楚的(如可發(fā)現(xiàn)的)漸進(jìn)。
漸進(jìn)API也可啟用從在較低難度和伴隨的控制能力的一點(diǎn)處發(fā)展到較高難度和伴隨的控制能力的一點(diǎn)的遞增前進(jìn)。下文描述了用于設(shè)計(jì)漸進(jìn)API以及一般高度可使用的API的示例性范例。
圖3在表300中示出了API的示例性設(shè)計(jì)原理和實(shí)踐。表300指示四個(gè)示例性類別302-308的一般設(shè)計(jì)原理和實(shí)踐。具體地，著眼于以下四個(gè)類別場(chǎng)景驅(qū)動(dòng)設(shè)計(jì)302、面向組件設(shè)計(jì)304、可定制默認(rèn)值306和自編對(duì)象模型308。
當(dāng)設(shè)計(jì)給定的API時(shí)，可采用用于指示的類別302-308的任一一個(gè)或多個(gè)的設(shè)計(jì)原理和實(shí)踐。此外，在任一給定的類別302-308內(nèi)，可實(shí)現(xiàn)所示的設(shè)計(jì)原理和實(shí)踐的一個(gè)或多個(gè)。換言之，不需要為給定的API設(shè)計(jì)采用或?qū)崿F(xiàn)每一類別或每一設(shè)計(jì)原理和實(shí)踐。
場(chǎng)景驅(qū)動(dòng)設(shè)計(jì)類別302示出了四個(gè)示例性設(shè)計(jì)原理和實(shí)踐。首先，定義了所選擇特征或技術(shù)區(qū)域的核心場(chǎng)景。第二，首先書寫對(duì)應(yīng)于該核心場(chǎng)景的代碼樣本，然后響應(yīng)于該代碼樣本設(shè)計(jì)API。第三，設(shè)計(jì)上文介紹并在后文進(jìn)一步描述的漸進(jìn)API。第四，將使用定義的核心場(chǎng)景變得簡(jiǎn)單，并將使用其它場(chǎng)景變得可能。在后文“場(chǎng)景驅(qū)動(dòng)設(shè)計(jì)”標(biāo)題下的部分中進(jìn)一步描述了場(chǎng)景驅(qū)動(dòng)設(shè)計(jì)302。
面向組件設(shè)計(jì)類別304示出了三個(gè)示例性設(shè)計(jì)原理和實(shí)踐。首先，創(chuàng)建聚集組件(AC)。一般地，聚集組件針對(duì)核心場(chǎng)景，它們相對(duì)簡(jiǎn)單且易于使用，并且在分解類型(FT)之上構(gòu)建。分解類型更基礎(chǔ)，并被分解成較低的邏輯層。這產(chǎn)生了一個(gè)兩層的API設(shè)計(jì)。第二，這些聚集組件與分解類型相互關(guān)聯(lián)。第三，支持創(chuàng)建—設(shè)置—調(diào)用用法模式，尤其對(duì)聚集組件。面向組件設(shè)計(jì)304在后文“面向組件設(shè)計(jì)”標(biāo)題下的部分中進(jìn)一步描述。
可定制默認(rèn)值類別306示出了兩個(gè)示例性設(shè)計(jì)原理和實(shí)踐。首先，減少了至少使用聚集組件的所需要的初始化。默認(rèn)值被用于減少所需要的初始化。第二，選擇適合于定義的核心場(chǎng)景的默認(rèn)值?？啥ㄖ颇J(rèn)值306在后文“可定制默認(rèn)值”標(biāo)題下的部分進(jìn)一步描述。
自編對(duì)象模型類別308示出了四個(gè)示例性設(shè)計(jì)原理和實(shí)踐。首先，為核心場(chǎng)景保存了簡(jiǎn)單且直觀的名字。第二，基于該組件類型的預(yù)期使用或目的，而非死板地堅(jiān)持繼承層次來(lái)選擇名字。第三，拋出可執(zhí)行行動(dòng)的異常，使得開發(fā)者接收指示如何從異常消息修補(bǔ)錯(cuò)誤的指令。第四，通過(guò)將偶爾使用的類型放置到子名字空間來(lái)生成干凈的名字空間，以避免弄亂主名字空間。自編對(duì)象模型308在后文“自編對(duì)象模型”標(biāo)題下的部分進(jìn)一步描述。
場(chǎng)景驅(qū)動(dòng)設(shè)計(jì)在一描述的實(shí)施中，API規(guī)范由場(chǎng)景驅(qū)動(dòng)。因此，API設(shè)計(jì)者首先書寫API的用戶必須要寫入核心(如，主)場(chǎng)景的代碼。API設(shè)計(jì)者然后設(shè)計(jì)對(duì)象模型來(lái)支持這些代碼樣本。該方法與開始設(shè)計(jì)對(duì)象模型(使用各種設(shè)計(jì)方法)并然后基于結(jié)果API書寫代碼樣本相反。
換言之，尤其是對(duì)公共API設(shè)計(jì)，API設(shè)計(jì)者從用于每一特征或技術(shù)區(qū)域的場(chǎng)景的列表以及其代碼樣本開始，生成基于其的標(biāo)題風(fēng)格對(duì)象模型描述。特征區(qū)域的示例包括文件I/O、網(wǎng)絡(luò)化、消息通信、控制臺(tái)(console)、診斷、數(shù)據(jù)庫(kù)存取、網(wǎng)頁(yè)、圖形用戶界面編程等等。
圖4所示是用于按特征區(qū)域設(shè)計(jì)API的示例性技術(shù)的流程圖。在塊402，為給定的特征區(qū)域選擇核心場(chǎng)景。例如，對(duì)于給定的技術(shù)區(qū)域，可選擇前5-10個(gè)場(chǎng)景。可以基于最常用的功能(如，最常見的任務(wù))或最頻繁追蹤的目標(biāo)為給定的技術(shù)區(qū)域選擇它們。例如，用于文件I/O技術(shù)特征區(qū)域的示例性場(chǎng)景是從文件讀取和寫入文件。
在塊404，以多種語(yǔ)言(如兩個(gè)或多個(gè))為核心場(chǎng)景書寫代碼樣本。例如，與所選擇的核心場(chǎng)景關(guān)聯(lián)的代碼樣本可以三種不同的語(yǔ)言書寫。該代碼樣本可以三種語(yǔ)言實(shí)現(xiàn)當(dāng)前選擇的核心場(chǎng)景。這類語(yǔ)言包括，例如，VB、C#、MC++、標(biāo)記語(yǔ)言等等；然而，也可以使用其它語(yǔ)言。如星號(hào)所指示的，應(yīng)當(dāng)理解，當(dāng)為單個(gè)語(yǔ)言設(shè)計(jì)可使用且功能強(qiáng)大API時(shí)，可以單個(gè)語(yǔ)言為核心場(chǎng)景書寫代碼樣本(或甚至一個(gè)以上代碼樣本)。
可以實(shí)現(xiàn)以多種語(yǔ)言書寫代碼樣本，因?yàn)橛袝r(shí)候以不同的語(yǔ)言書寫的代碼有顯著的不同。在描述的實(shí)現(xiàn)中，用于當(dāng)前選擇的核心場(chǎng)景的代碼樣本使用具體語(yǔ)言的用戶中常見的不同代碼風(fēng)格來(lái)書寫(如，使用語(yǔ)言專用的特征或特性、使用開發(fā)者的慣例/習(xí)慣等等)，以該具體語(yǔ)言書寫的具體的代碼樣本。例如，可使用語(yǔ)言專用包裝來(lái)書寫樣本。例如，VB是對(duì)包裝不敏感的，因此以VB書寫的代碼樣本反映該可變性。另一方面，以C#書寫的代碼樣本遵循其標(biāo)準(zhǔn)的包裝。
另一示例涉及稱為“使用”的語(yǔ)句，由C#支持。例如，“使用”調(diào)用封裝嘗試/最終(try/finally)塊。然而，VB不支持該特征，并且書寫代碼樣本可指示在嘗試/最終語(yǔ)句中使用該特征對(duì)VB用戶是笨拙的。再一示例涉及條件子句中的賦值，由C#支持。在文件I/O實(shí)例中，“if((text＝reader.ReadLine()?。絥ull)”在C#中起作用。然而，該賦值語(yǔ)句無(wú)法在VB的“if”子句中使用；相反，該代碼被分裂為多個(gè)語(yǔ)句。又一示例涉及C#開發(fā)者使用參數(shù)化的構(gòu)造函數(shù)的傾向，而VB開發(fā)者通常沒有該傾向。例如，C#代碼可以是“MyClass x＝new MyClass(″value″)”，而對(duì)應(yīng)的VB代碼為“Dim x As MyClass”以及“xProperty＝″value″”。
在塊406，響應(yīng)于以多種語(yǔ)言書寫代碼樣本，從當(dāng)前的核心場(chǎng)景衍生API。例如，從以多種語(yǔ)言的每一種書寫的代碼樣本中收集的因素可結(jié)合進(jìn)API中。這類因素可包括跨不同代碼樣本的類似性、兩個(gè)或多個(gè)代碼樣本之間/之中的差異等等。這類因素以及塊404和406的其它方面在下文參考圖5進(jìn)一步描述。
類似地，當(dāng)為單個(gè)語(yǔ)言設(shè)計(jì)API時(shí)，響應(yīng)于以單個(gè)語(yǔ)言書寫的(多個(gè))代碼樣本從當(dāng)前的核心場(chǎng)景衍生該API。由此，從以單個(gè)語(yǔ)言書寫的(多個(gè))代碼樣本收集的因素可結(jié)合進(jìn)該API中。作為用于單個(gè)或多個(gè)語(yǔ)言情況的另外的API設(shè)計(jì)因素示例，API設(shè)計(jì)因素可包括與面向?yàn)槠鋾鴮?多個(gè))代碼樣本的一種或多種語(yǔ)言的工具的兼容性。
在塊408，確定該API是否過(guò)于復(fù)雜。例如，可由(多個(gè))API設(shè)計(jì)者審閱該API來(lái)確定該API是否過(guò)于復(fù)雜。換言之，可執(zhí)行初始檢查來(lái)考慮是否能在不顯著理解多個(gè)其它具體的API的情況下，在不進(jìn)行不適當(dāng)?shù)脑囼?yàn)的情況下等使用該API。這一初始檢查也可核實(shí)衍生的API實(shí)際上能以每一相關(guān)語(yǔ)言在當(dāng)前核心場(chǎng)景下起作用。如果該API太過(guò)復(fù)雜，則由設(shè)計(jì)者參考當(dāng)前核心場(chǎng)景并響應(yīng)于在塊406中以多種語(yǔ)言書寫的代碼樣本提煉該API。
另一方面，如果確定該API不是太過(guò)復(fù)雜(在塊408)，則在塊410，執(zhí)行典型的開發(fā)者可用性學(xué)習(xí)。例如，可使用與典型的開發(fā)者通常使用的開發(fā)環(huán)境類似的開發(fā)環(huán)境來(lái)執(zhí)行一個(gè)或多個(gè)可用性學(xué)習(xí)。這一普通的開發(fā)環(huán)境可包括智能感知(intellisense)、編輯器、語(yǔ)言以及由目標(biāo)開發(fā)者組最廣泛使用的文檔集。
可用性學(xué)習(xí)以很大范圍的開發(fā)者為目標(biāo)的可用性學(xué)習(xí)方便了場(chǎng)景驅(qū)動(dòng)設(shè)計(jì)，尤其是當(dāng)設(shè)計(jì)一般公共API的時(shí)候。由API設(shè)計(jì)者為核心場(chǎng)景書寫的代碼樣本可能看似對(duì)他們簡(jiǎn)單，但是該代碼樣本可能對(duì)實(shí)際上目標(biāo)的某些開發(fā)者組(如，尤其是新手和/或偶爾為之的開發(fā)者)不是同樣的簡(jiǎn)單。另外，通過(guò)可用性學(xué)習(xí)儲(chǔ)存的關(guān)于開發(fā)者處理每一核心場(chǎng)景的方式的理解可將提供對(duì)API的設(shè)計(jì)的強(qiáng)大的洞察力，以及它如何滿足所有目標(biāo)的開發(fā)者的需求。
一般地，可用性學(xué)習(xí)可在產(chǎn)品周期的早期執(zhí)行，并且在對(duì)象模型的任一主要重設(shè)計(jì)之后再次執(zhí)行。盡管這是一種成本較大的設(shè)計(jì)實(shí)踐，它實(shí)際上能夠從長(zhǎng)遠(yuǎn)看來(lái)節(jié)省資源。在不引入中斷的改變的情況下修補(bǔ)不可用或僅有缺陷的API的成本將是巨大的。
在塊412，確認(rèn)典型的開發(fā)者是否能夠在沒有重大問題的情況下使用API。例如，大多數(shù)對(duì)象應(yīng)當(dāng)能夠在沒有主要問題的情況下為當(dāng)前選擇的場(chǎng)景書寫代碼。如果他們無(wú)法書寫，則修訂該API(如后文參考?jí)K414描述的)。
重大/主要問題的解釋由對(duì)給定的目標(biāo)開發(fā)者組的可用性的期望的級(jí)別所決定。例如，測(cè)試對(duì)象對(duì)當(dāng)前核心場(chǎng)景的詳細(xì)API文檔的頻繁和/或廣泛的引用可構(gòu)成重大問題。一般，如果大多數(shù)測(cè)試開發(fā)者無(wú)法實(shí)現(xiàn)當(dāng)前核心場(chǎng)景，或者如果他們所采取的方法與所期望的顯著不同，則應(yīng)當(dāng)為可能的修訂評(píng)估該API(直到并包括完整的重設(shè)計(jì))。
如果確認(rèn)典型的開發(fā)者無(wú)法在沒有重大問題的情況下使用該API(在塊412)，則在塊414，基于來(lái)自可用性學(xué)習(xí)的經(jīng)驗(yàn)修訂API。例如，可改變默認(rèn)值、可添加另一特性、可將一個(gè)或多個(gè)屬性展現(xiàn)而不是封裝，等等。
另一方面，如果確認(rèn)典型的開發(fā)者能夠在沒有重大問題的情況下使用該API(在塊412)，則在塊416，對(duì)每一核心場(chǎng)景重復(fù)該過(guò)程。例如，對(duì)給定特征選擇的諸核心場(chǎng)景中的另一核心場(chǎng)景變?yōu)闉槠鋾鴮懘a樣本(在塊404)的當(dāng)前核心場(chǎng)景。用于設(shè)計(jì)API的另一示例性示例更多地集中于兩層API設(shè)計(jì)，在下文結(jié)合圖8進(jìn)一步描述。
圖5所示是用于按核心場(chǎng)景設(shè)計(jì)API的示例性模式的框圖404/406。所示的示例性模式對(duì)應(yīng)于圖4的塊404和406，用于多語(yǔ)言實(shí)現(xiàn)。示出了用于第一語(yǔ)言的代碼樣本502(1)、用于第二語(yǔ)言的代碼樣本502(2)以及用于第三語(yǔ)言的代碼樣本502(3)。這三個(gè)代碼樣本502(1，2，3)的每一個(gè)都針對(duì)給定的當(dāng)前核心場(chǎng)景。盡管示出了對(duì)應(yīng)于三種語(yǔ)言的三個(gè)代碼樣本502(1，2，3)，可在該示例性多語(yǔ)言實(shí)現(xiàn)中替換地使用任意數(shù)量的目標(biāo)語(yǔ)言的兩個(gè)或多個(gè)代碼樣本502。
在描述的實(shí)現(xiàn)中，從以這三種語(yǔ)言的每一種書寫的代碼樣本502(1，2，3)收集因素506。這些因素506被結(jié)合進(jìn)API 504中。具體地，API 504被設(shè)計(jì)成支持以三種各自對(duì)應(yīng)的語(yǔ)言書寫的三個(gè)代碼樣本502(1，2，3)。然而，應(yīng)當(dāng)理解，因素506也可以應(yīng)用到單語(yǔ)言實(shí)現(xiàn)。
以上參考圖4的塊404和406描述了一些示例性因素506，其它示例性因素506在圖5的框圖404/406中指示。這些因素506包括由代碼樣本502(1，2，3)的審閱所展現(xiàn)的語(yǔ)言專用命令。就以下示例代碼行“Foo f＝new Foo()；”描述了語(yǔ)言專用約束的一個(gè)示例。被設(shè)計(jì)成支持該示例行的漸進(jìn)API必須包括默認(rèn)構(gòu)造函數(shù)；否則，該代碼樣本無(wú)法正確編譯。
因素506也包括由語(yǔ)言特質(zhì)和自然地傾向于不同語(yǔ)言的典型開發(fā)者的不同的技能/經(jīng)驗(yàn)級(jí)別所引入的開發(fā)者期望。因素506還包括如可由代碼樣本502(1，2，3)的審閱發(fā)現(xiàn)的跨越不同語(yǔ)言的代碼通用性和書寫代碼的慣例。
在考慮直接與不同語(yǔ)言有關(guān)的因素506的同時(shí)，還繼續(xù)考慮了其它在此所描述的因素506。例如，以下因素506與以單個(gè)語(yǔ)言環(huán)境為目標(biāo)的漸進(jìn)API的有關(guān)，又與多語(yǔ)言環(huán)境的有關(guān)。首先，完成場(chǎng)景所需要的若干不同的組件類型是一個(gè)因素。一般地，需要的組件類型越多，學(xué)習(xí)起來(lái)就越難。第二個(gè)因素是代碼的連續(xù)行之間的連接。一個(gè)組件類型的使用將開發(fā)者引向下一需要的組件類型的使用的程度，即該API更易于使用的程度。
第三，標(biāo)識(shí)符的命名中的一致性是另一因素。第四個(gè)因素涉及特性、方法和事件的適當(dāng)使用。第五個(gè)因素涉及對(duì)一個(gè)或多個(gè)現(xiàn)有API的可能的類似性。第六，另一因素涉及符合API的整體設(shè)計(jì)方針。第七個(gè)因素涉及該API是否與該框架的其它組件類型重疊。第八，與面向具體語(yǔ)言的工具的兼容性是再一因素。例如，VB開發(fā)者通常想要少參數(shù)的構(gòu)造函數(shù)和特性設(shè)定函數(shù)。可替換地考慮其它因素506。
下文描述了涉及聚集組件和分解類型的相互關(guān)系的又一些其它因素506，特別參考圖8。盡管圖4和5的方法和模式可一般應(yīng)用到設(shè)計(jì)API中，它們尤其可適用到設(shè)計(jì)雙層API中。下文參考圖6-8在“面向組件的設(shè)計(jì)”標(biāo)題下的部分中描述了雙層API范例(如具有聚集組件和分解類型)。
面向組件的設(shè)計(jì)圖6沿連續(xù)區(qū)(continuum)600示出了以兩個(gè)不同目的為目標(biāo)的示例性組件類型602之間的潛在不一致性。連續(xù)區(qū)600從左側(cè)的高可用性區(qū)段延伸到右側(cè)的高可控制性區(qū)段。多個(gè)組件類型602跨連續(xù)區(qū)600分布。
一般地，示出為相對(duì)較大的組件類型602標(biāo)識(shí)較簡(jiǎn)單并因此較易于使用的類型。相反地，示出為相對(duì)較小的組件類型602標(biāo)識(shí)較復(fù)雜并因此較難使用的類型。本上下文中的“簡(jiǎn)單”和“復(fù)雜”是指當(dāng)實(shí)現(xiàn)指定的場(chǎng)景時(shí)具體的組件類型602的使用如何簡(jiǎn)單或如何困難。
示出為相對(duì)較小的組件類型602由于如下的若干示例性原因一般更難使用首先，開發(fā)者具有他們應(yīng)當(dāng)使用哪些組件類型602的更多選擇。在示出的示例中，與對(duì)較大組件類型602的三個(gè)“選擇”相比，對(duì)較小組件類型602有14個(gè)“選擇”。更具體地，開發(fā)者必須知道或看出，在各種組件類型602(HC)中使用哪一或哪些組件類型。這涉及理解多個(gè)組件類型602(HC)的每一個(gè)以及它們?nèi)绾蜗嗷ハ嚓P(guān)，這與從較少組件類型602(HU)中單個(gè)組件類型602(HU)開始相反。組件類型602(HU)和組件類型602(HC)之間的差異在后文進(jìn)一步描述。
作為示例性類比，較小的組件類型602與立體聲系統(tǒng)的個(gè)別組件相似；因此，用戶必須知道需要哪一組件并如何將它們鉤掛在一起。如果不將它們鉤掛在一起，它們一般是沒用的。較大的組件類型602與易于使用但是可能功能較不強(qiáng)大并且較不靈活的一體化立體聲裝置相似。較小的組件類型602較難使用的第二個(gè)原因是潛在地有更多的“出發(fā)點(diǎn)”。第三，一般有更多的概念要理解。第四，開發(fā)者必須理解個(gè)別的組件類型602如何與其它組件類型602相關(guān)。
在描述的實(shí)現(xiàn)中，組件類型602被劃分成具有高可用性目的的組件類型602(HU)和具有高可控制性目的的組件類型602(HC)。高可用性組件類型602(HU)更簡(jiǎn)單且更易于使用，但是它們往往更不靈活、更限制和/或更有約束。它們一般可以在不具有整體API的廣泛的知識(shí)的情況下使用。高可用性組件類型602(HU)通常能夠?qū)崿F(xiàn)有限數(shù)量的場(chǎng)景或最多對(duì)感興趣的每一場(chǎng)景的有限數(shù)量的方法。
另一方面，高可控制性組件類型602(HC)的使用復(fù)雜，但是它們向開發(fā)者提供更大程度的控制。它們相對(duì)功能強(qiáng)大，并令開發(fā)者能夠完成低層調(diào)節(jié)和調(diào)整。然而，使用高可控制行組件類型602(HC)開發(fā)需要許多組件類型602的更完整的理解，以啟用正確地連接到實(shí)現(xiàn)甚至是相對(duì)直接的場(chǎng)景的多個(gè)高可控制性組件類型602(HC)的例示。
通常，高可用性組件類型602(HU)在諸如VB等介紹性語(yǔ)言中存在，而高可控制性組件類型602(HC)在諸如C++等高級(jí)專業(yè)程序員類型語(yǔ)言中存在。圖6示出的高可用性組件類型602(HU)和高可控制性組件類型602(HC)之間的潛在不一致性至少部分地由圖7的組件類型702改善。具體地，高可用性組件類型602(HU)和高可控制性組件類型602(HC)之間的相互關(guān)系由漸進(jìn)API建立。
圖7沿連續(xù)區(qū)700示出了被設(shè)計(jì)成可擴(kuò)充和/或可相互操作以覆蓋至少兩個(gè)目的的組件類型702之間的示例性關(guān)系。在描述的實(shí)現(xiàn)中，具有高可用性目的的組件類型被實(shí)現(xiàn)為聚集組件602(AC)，而具有高可控制性目的的組件類型被實(shí)現(xiàn)為分解類型702(FT)。盡管組件類型702僅被劃分成兩個(gè)目的，然而可替換地它們被分割成三個(gè)或更多的目的(或其它類別)。
關(guān)鍵字704指示實(shí)線表示展現(xiàn)的分解類型之間的關(guān)系，而虛線表示封裝的分解類型之間的關(guān)系。如圖所示，聚集組件702(AC)(1)與三個(gè)分解類型702(FT)有關(guān)系。具體地，分解類型702(FT)(1)與聚集組件702(AC)(1)有展現(xiàn)分解類型的關(guān)系，分解類型702(FT)(2)和702(FT)(3)與聚集組件702(AC)(1)有封裝分解類型的關(guān)系。
盡管未如此示出，但兩個(gè)或多個(gè)聚集組件702(AC)可與同一分解類型702(FT)有封裝的和/或展現(xiàn)的關(guān)系。展現(xiàn)的和封裝的分解類型702(FT)和聚集組件702(AC)及其之間的關(guān)系在后文進(jìn)一步描述，包括參考圖8。
面向組件的設(shè)計(jì)涉及為每一用戶概念提供單個(gè)對(duì)象，與每一邏輯概念需要多個(gè)對(duì)象相反。因此，聚集組件通常對(duì)應(yīng)于用戶概念，并且從可用性觀點(diǎn)來(lái)看更簡(jiǎn)單。聚集組件層位于分解類型層之上。作為示例性比較，聚集組件可模型化諸如文件等事物，而分解類型可模型化諸如文件上的視圖等事物的狀態(tài)。聚集組件和分解類型一起為新開發(fā)者提供了漸進(jìn)且逐步的學(xué)習(xí)曲線，尤其是關(guān)于具體的給定的API。
對(duì)聚集組件(aggregate component)的面向組件的設(shè)計(jì)許多特征區(qū)域可得益于擔(dān)當(dāng)更復(fù)雜但較佳分解的剩余的特征區(qū)域API的簡(jiǎn)化視圖的外表類型。在描述的實(shí)現(xiàn)中，外表覆蓋了給定特征區(qū)域以及可任選的其它高級(jí)操作中前5-10個(gè)場(chǎng)景。聚集組件702(AC)可起這一外表類型的作用，而分解類型702(FT)可提供剩余的較佳分解的復(fù)雜API景象。
每一聚集組件將多個(gè)低層分解類捆綁到高層組件以支持最前的核心場(chǎng)景。例如，郵件聚集組件可與STMP協(xié)議、套接字、編碼等捆綁在一起。一般地，每一聚集組件提供較高的抽象級(jí)別而非僅做事情的不同方法。提供簡(jiǎn)化的高級(jí)操作對(duì)不想學(xué)習(xí)由特征區(qū)域提供的功能的整體并僅希望在沒有大量學(xué)習(xí)或API探究的情況下實(shí)現(xiàn)其經(jīng)常是十分簡(jiǎn)單的任務(wù)的開發(fā)者來(lái)說(shuō)是有益的。
一般地，面向組件的設(shè)計(jì)是基于構(gòu)造函數(shù)、特性、方法和事件的設(shè)計(jì)。使用聚集組件是面向組件的設(shè)計(jì)的相對(duì)極端的應(yīng)用。以下提供了用于聚集組件的面向組件的設(shè)計(jì)的一組示例性參數(shù)構(gòu)造函數(shù)聚集組件具有默認(rèn)(少參數(shù))的構(gòu)造函數(shù)。
構(gòu)造函數(shù)對(duì)應(yīng)于特性的可任選構(gòu)造函數(shù)參數(shù)。
特性大多數(shù)特性具有獲取函數(shù)和設(shè)置函數(shù)。
特性特性具有相當(dāng)?shù)?sensible)默認(rèn)值。
方法如果參數(shù)指定了跨方法調(diào)用(在選擇的核心場(chǎng)景中)保持恒定的選項(xiàng)，則方法不采用該參數(shù)。這一選項(xiàng)可使用特性來(lái)指定。
事件方法不將委托作為參數(shù)采用?；亟邪凑帐录?lái)實(shí)現(xiàn)。
面向組件的設(shè)計(jì)需要考慮如何使用API而非集中于在對(duì)象模型中純粹引入方法、特性和事件上。用于面向組件的設(shè)計(jì)的一個(gè)示例性使用涉及用默認(rèn)或相對(duì)簡(jiǎn)單的構(gòu)造函數(shù)例示類型、在該實(shí)例上設(shè)置某些特性然后調(diào)用簡(jiǎn)單的方法的模式。該模式被稱為創(chuàng)建—設(shè)置—調(diào)用用法模式。一般的示例如下‘VB‘例示‘Dim T As New T()‘設(shè)置特性/選項(xiàng)T.P1＝V1T.P2＝V2T.P3＝V3
‘調(diào)用方法；可任選地在調(diào)用之間改變選項(xiàng)T.M1()T.P3＝V4T.M2()當(dāng)聚集組件支持這一創(chuàng)建—設(shè)置—調(diào)用用法模式時(shí)，聚集組件與聚集組件的主要用戶的期望相一致。此外，為該用法模式優(yōu)化諸如智能感知和設(shè)計(jì)程序等工具。示出創(chuàng)建—設(shè)置—調(diào)用用法模式的具體代碼示例如下‘VB‘例示Dim File As New FileObject()‘設(shè)置特性File.Filename＝″c\foo.txt″File.Encoding＝Encoding.Ascii‘調(diào)用方法File.Open(OpenMode.Write)File.WriteLine(″Hello World″)File.Close()采用作為漸進(jìn)API的一部分的示例性聚集組件，設(shè)置“File.Encoding”特性是可任選的。如果未指定，則API具有預(yù)選擇的文件編碼的默認(rèn)值。類似地，對(duì)于“File.Open()”，指定“OpenMode.Write”是可任選的。如果未指定，則采用API預(yù)選擇的默認(rèn)“OpenMode(打開模式)”面向組件的設(shè)計(jì)的一個(gè)問題是它導(dǎo)致具有模式和無(wú)效狀態(tài)的類型。例如，默認(rèn)構(gòu)造函數(shù)允許用戶在不指定“FileName(文件名)”的情況下例示“FileObject(文件對(duì)象)”。在沒有首先設(shè)置“FileName”的情況下嘗試調(diào)用Open()(打開)導(dǎo)致異常，因?yàn)椤癋ileObject”對(duì)于要打開是無(wú)效的狀態(tài)(如，尚未指定文件名)。另一問題是可以被可任選并獨(dú)立地設(shè)置的特性并不強(qiáng)制一致性以及對(duì)該對(duì)象的狀態(tài)的原子變化。此外，這一“模態(tài)”性質(zhì)抑制了消費(fèi)者之間對(duì)象實(shí)例的共享，因?yàn)榈谝挥脩舯仨氃谥匦率褂盟皺z查先前設(shè)定的值，以防萬(wàn)一第二用戶在中間時(shí)期改變?cè)撝?。然而，聚集組件的可用性對(duì)于大多數(shù)開發(fā)者來(lái)說(shuō)比這些問題更重要。
當(dāng)用戶調(diào)用對(duì)象的當(dāng)前狀態(tài)中不有效的方法時(shí)，拋出“InvalidOperationException(無(wú)效操作異常)”。該異常的消息可清楚地解釋需要改變哪些特性以將該對(duì)象放入有效狀態(tài)。這些清楚的異常消息部分地克服了無(wú)效狀態(tài)問題，并導(dǎo)致更自編的對(duì)象模型。
API設(shè)計(jì)者經(jīng)常試圖設(shè)計(jì)類型，使得對(duì)象無(wú)法在無(wú)效狀態(tài)中存在。例如，這可以通過(guò)令所有需要的設(shè)置作為構(gòu)造函數(shù)的參數(shù)、通過(guò)具有在例示后無(wú)法改變的設(shè)置的僅可獲取(get-only)特性、通過(guò)將功能分隔成單獨(dú)的類型使得特性和方法不重疊來(lái)實(shí)現(xiàn)。在描述的實(shí)現(xiàn)中，使用分解類型而非聚集組件來(lái)采用該方法。對(duì)于聚集組件，向開發(fā)者提供了向其傳遞無(wú)效狀態(tài)的清楚的異常。當(dāng)執(zhí)行操作而非初始化組件(如，當(dāng)調(diào)用構(gòu)造函數(shù)或設(shè)置特性)時(shí)可以拋出這些清楚的異常，以避免無(wú)效狀態(tài)是臨時(shí)的，并且在隨后的代碼行中被“修補(bǔ)”的情況。
分解類型(Factored Types)如上所述，聚集組件為大多數(shù)常見高級(jí)操作提供了快捷方式，并通常被實(shí)現(xiàn)為一組更復(fù)雜但也更豐富類型，稱為分解類型上的外表。在描述的實(shí)現(xiàn)中，分解類型不具有模式，并且不具有十分明確的生存期。
聚集組件可提供通過(guò)某些特性和/或方法到其內(nèi)部分解類型的訪問。用戶在相對(duì)高級(jí)的場(chǎng)景或需要與系統(tǒng)的不同部分的集成的場(chǎng)景中訪問內(nèi)部分解類型。由聚集組件使用的訪問分解類型的能力令使用聚集組件書寫的代碼能夠遞增地為先進(jìn)的場(chǎng)景添加復(fù)雜度，或與其它組件類型集成，而不需要集中在使用分解類型上從頭開始重新寫代碼。
以下實(shí)例示出了展現(xiàn)其示例性內(nèi)部分解類型(“StreamWriter”)的示例性聚集組件(“FileObject”)‘VBDim File As New FileObject(″c\foo.txt″)File.Open(OpenMode.Write)
File.WriteLine(″Hello World″)AppendMessageToTheWorld(File.StreamWriter)File.Close()Public Sub AppendMessageToTheWorld(ByVal Writer As Stream Writer)End Sub高級(jí)操作在描述的實(shí)現(xiàn)中，實(shí)現(xiàn)了作為上層或高層API(如，從抽象程度來(lái)看)的聚集組件，使得它們看似能夠在用戶不知道有時(shí)候在下面發(fā)生了一些復(fù)雜的事情的情況下“魔法般地”起作用。例如，“EventLog(事件記錄)”聚集組件隱藏了記錄具有讀句柄和寫句柄的事實(shí)，這兩個(gè)句柄都要被打開以使用該組件。就開發(fā)者來(lái)看，聚集組件可以被例示、特性可以被設(shè)置并且可以在不關(guān)心底下功能的情況下書寫記錄事件。
在某些情況中，稍微更多的透明性可方便開發(fā)者的某一任務(wù)。一個(gè)示例是這樣的操作，在其中用戶采取顯式行動(dòng)作為操作的結(jié)果。例如，隱含地打開范文然后需要用戶顯式地關(guān)閉它可能是將“魔法般地”起作用的原理帶地太遠(yuǎn)了。然而，勤奮的API開發(fā)者可經(jīng)常能夠設(shè)計(jì)甚至隱藏這些復(fù)雜度的聰明的解決方案。例如，讀文件可被實(shí)現(xiàn)為打開文件、讀其內(nèi)容并關(guān)閉它的單個(gè)操作；由此，保護(hù)了用戶免遭涉及打開和關(guān)閉文件句柄的復(fù)雜度。
此外，使用聚集組件不涉及實(shí)現(xiàn)任何接口、修改任何配置文件等等。相反，庫(kù)設(shè)計(jì)者可采用已聲明的接口的默認(rèn)實(shí)現(xiàn)。此外，配置設(shè)置是可任選的，并由敏感(sensible)默認(rèn)支持。
圖8示出了用于處理具有雙層API 800的兩個(gè)不同目的的示例性聚集組件702(AC)和關(guān)聯(lián)的分解類型702(FT)。聚集組件702(AC)表示第一或較高層，分解類型702(FT)表示第二或較低層。第一層采用自定義接口在第二層上有效地構(gòu)建。
如圖所示，聚集組件702(AC)包括多個(gè)聚集組件(AC)成員802。具體地，示出了聚集組件成員802(1)、802(2)、802(P)(1)、802(P)(2)、802(M)(1)、802(M)(2)和802(M)(3)。聚集組件702(AC)也包括展現(xiàn)的分解類型702(FT-Ex)以及封裝的分解類型702(FT-En)。具體地，示出了展現(xiàn)的分解類型702(FT-Ex)(1)和702(FT-Ex)(2)，以及封裝的分解類型702(FT-En)(1)和702(FT-En)(2)。分解類型702(FT)也包括分解類型(FT)成員804。
在描述的實(shí)現(xiàn)中，聚集組件702(AC)包括至少一個(gè)聚集組件成員802，例如，它可以是方法或特性。因此，聚集組件成員802可包括聚集組件方法802(M)和聚集組件特性802(P)。這些聚集組件成員802，如聚集組件成員802(1)和802(2)，可以對(duì)聚集組件702(AC)專用。換言之，某些聚集組件成員802，如聚集組件702(AC)上的聚集組件成員802(1)和802(2)可不依賴于任何分解類型702(FT)。可選地，某些聚集組件成員802可連接到基礎(chǔ)分解類型702(FT)。
分解類型702(FT)可以是展現(xiàn)的分解類型702(FT-Ex)或封裝的分解類型702(FT-En)。展現(xiàn)的分解類型702(FT-Ex)是在不使用或經(jīng)歷給定聚集組件702(AC)的個(gè)別聚集組件成員802的情況下可由或?qū)ζ渌话憬M件類型702(FT或AC)訪問的給定聚集組件702(AC)的分解類型702(FT)。如果分解類型702(FT-Ex/En)由聚集組件成員802(或者是方法或者是特性)返回，則展現(xiàn)該分解類型702(FT-Ex)。否則，封裝該分解類型702(FT-En)。
換言之，聚集組件成員802可展現(xiàn)分解類型成員802，或者聚集組件成員802可返回分解類型實(shí)例。后者可在展現(xiàn)的分解類型702(FT-Ex)出現(xiàn)，前者可在封裝的分解類型702(FT-En)出現(xiàn)。封裝的分解類型702(FT-En)是包含在給定聚集組件702(AC)之內(nèi)或?qū)ζ錇閮?nèi)部的給定聚集組件702(AC)的分解類型702(FT)。每一分解類型702(FT)可包括作為方法和/或特性的一個(gè)或多個(gè)成員804(其某些在圖8中具體指示)。
如圖所示，由聚集組件702(AC)展現(xiàn)了封裝的分解類型702(FT-En)(1)的兩個(gè)方法成員804，為方法成員802(M)(1)和方法成員802(M)(2)。由聚集組件702(AC)展現(xiàn)了封裝的分解類型702(FT-En)(2)的一個(gè)方法成員804，為方法成員802(M)(3)。
展現(xiàn)的分解類型702(FT-Ex)(1)本身被展現(xiàn)為聚集組件702(AC)的特性成員802(P)(1)。類似地，展現(xiàn)的分解類型702(FT-Ex)(2)也被展現(xiàn)為聚集組件702(AC)的特性成員802(P)(2)。如圖所示，展現(xiàn)了展現(xiàn)的分解類型702(FT-Ex)(1)的分解類型(FT)成員804以使其單獨(dú)可訪問(即，在不直接使用聚集組件702(AC)的個(gè)別成員802的情況下可訪問)。因此，即使不由聚集組件702(AC)的聚集組件成員802個(gè)別地展現(xiàn)，展現(xiàn)的分解類型702(FT-Ex)的分解類型成員804仍可以被訪問。
由此，展現(xiàn)了展現(xiàn)的分解類型702(FT-Ex)(1)的指示的成員804以使其在不使用其成員802的情況下可由對(duì)聚集組件702(AC)尾部的組件類型702訪問。如從展現(xiàn)的分解類型702(FT-Ex)(1)發(fā)源的虛線所指示的，可“傳送”(handed off)展現(xiàn)的分解類型702(FT-Ex)，以由不能與聚集組件702(AC)交互或者可單獨(dú)使用傳送的展現(xiàn)的分解類型702(FT-Ex)(1)來(lái)更好地達(dá)到其預(yù)期的目的的其它組件類型702(尤其是由其它分解類型702(FT))使用。應(yīng)當(dāng)注意，被“傳送”的對(duì)象(展現(xiàn)的分解類型702(FT-Ex)(1))不是一個(gè)副本而是展現(xiàn)聚集組件702(AC)的一個(gè)實(shí)際的部分。結(jié)果，對(duì)傳送對(duì)象的操作影響聚集組件702(AC)。
一般地，如果封裝了分解類型702(FT)，則它不向消費(fèi)者展現(xiàn)；相反，在聚集組件702(AC)上設(shè)置特性802(P)或調(diào)用方法802(M)可促使基礎(chǔ)分解類型702(FT)上分解類型702(FT)被創(chuàng)建、特性804被設(shè)置或者方法804被調(diào)用。這些成員802和804可能不具有一對(duì)一的對(duì)應(yīng)性；例如，在聚集組件702(AC)上設(shè)置若干特性802(P)可在聚集組件702(AC)中高速緩存。隨后在聚集組件702(AC)上調(diào)用方法802(M)可促使將若干特性802(P)的先前指定的值用作對(duì)分解類型702(FT)的構(gòu)造函數(shù)自變量來(lái)創(chuàng)建分解類型702(FT)。
在描述的實(shí)現(xiàn)中，聚集組件702(AC)除展現(xiàn)的分解類型702(FT-Ex)的展現(xiàn)之外，與更傳統(tǒng)的面向?qū)ο蠼M件在兩種方式上不同。首先，聚集組件不必要展現(xiàn)其所有分解類型702(FT)的每一成員804。換言之，聚集組件702(AC)不嚴(yán)格地專用于繼承層次。第二，聚集組件702(AC)可具有模式，并由此可周期性地具有導(dǎo)致無(wú)效操作的狀態(tài)。
作為對(duì)關(guān)于因素506(圖5)的面向組件設(shè)計(jì)的方針，在聚集組件702(AC)內(nèi)展現(xiàn)或封裝分解類型702(FT)可基于若干因素的一個(gè)或多個(gè)。首先，如果一個(gè)特定的分解類型702(FT)包括不由給定的聚集組件702(AC)展現(xiàn)的功能，則將該特定的分解類型702(FT)展現(xiàn)為給定聚集組件702(AC)的特性成員802(P)。第二，如果該框架的其它一般組件類型702可從對(duì)一個(gè)特定的分解類型702(FT)的直接消費(fèi)的傳送中獲益，則將該特定的分解類型702(FT)展現(xiàn)為給定聚集組件702(AC)的特性成員802(P)。另一方面，當(dāng)一個(gè)特定的分解類型702(FT)完全由給定的聚集組件702(AC)展現(xiàn)，并且當(dāng)特定的分解類型702(FT)對(duì)向其它組件類型702的傳送無(wú)用時(shí)，不展現(xiàn)特定的分解類型702(FT)(并因此它被封裝)。
開發(fā)者可從聚集組件702(AC)開始，尤其是對(duì)于實(shí)現(xiàn)更簡(jiǎn)單和/或核心場(chǎng)景。當(dāng)開發(fā)者想要或需要實(shí)現(xiàn)更復(fù)雜的場(chǎng)景時(shí)，開發(fā)者可遞增并逐步地隨時(shí)問開始直接訪問并使用展現(xiàn)的分解類型702(FT-Ex)，包括其低層屬性。依賴于較簡(jiǎn)單的聚集組件702(AC)的原始代碼不需要被丟棄并且用完全依賴于分解類型702(FT)的更復(fù)雜的代碼來(lái)替換。該API框架的兩層可在各個(gè)部分中使用，并可同時(shí)共存。
設(shè)計(jì)雙層API框架可以使用以下示例性技術(shù)來(lái)實(shí)現(xiàn)，它以十個(gè)階段描述首先，選擇特定的特征區(qū)域的一組核心場(chǎng)景。其次，為選擇的核心場(chǎng)景書寫示出較佳的代碼行的代碼樣本。第三，從代碼行用適當(dāng)?shù)姆椒?、默認(rèn)值、抽象、命名等衍生聚集組件以支持該代碼樣本。
第四，依照衍生的聚集組件在適當(dāng)時(shí)提煉來(lái)自第二階段的代碼樣本。第五，評(píng)估提煉的代碼樣本是否足夠簡(jiǎn)單。如果不是，則該技術(shù)再次在第三階段繼續(xù)。如果是，則在第六階段確定是否存在另外的場(chǎng)景、使用、與其它組件的交互和/或其它需求。第七，API設(shè)計(jì)者判定第六階段發(fā)現(xiàn)的任何另外的需求是否可被添加到聚集組件，而無(wú)需向選擇的核心場(chǎng)景添加陡峭的復(fù)雜度。
第八，如果另外的需求不能被添加到聚集組件，則基于第七階段定義分解類型的全功能組的理想分解(如，基于面向?qū)ο蠡蚱渌治龇椒?。第九，確定聚集組件如何并是否封裝或展現(xiàn)來(lái)自第八階段中定義的分解類型的功能。第十，在適當(dāng)時(shí)提煉分解類型以支持聚集組件以及另外的需求。使用這一示例性技術(shù)，可設(shè)計(jì)具有聚集組件702(AC)和分解類型702(FT)的雙層API框架。
圖9示出了支持創(chuàng)建—設(shè)置—調(diào)用用法模式的示例性聚集組件702(AC)和關(guān)聯(lián)的API 902、802(P)、802(M)和904。示出了以下示例性API組構(gòu)造函數(shù)902、特性802(P)、方法802(M)和事件904。采用創(chuàng)建—設(shè)置—調(diào)用用法模式，最初由開發(fā)者依賴于默認(rèn)(如，少參數(shù))構(gòu)造函數(shù)902創(chuàng)建聚集組件702(AC)的實(shí)例。
第二，開發(fā)者設(shè)置任何默認(rèn)值對(duì)其不合適和/或?qū)?duì)象的預(yù)期使用非較佳的任何特性802(P)。第三，由開發(fā)者調(diào)用期望的方法802(M)。然后按照事件904實(shí)現(xiàn)回叫。
可定制默認(rèn)值可定制默認(rèn)值涉及只要至少對(duì)聚集組件可行就具有默認(rèn)值。當(dāng)例如采用對(duì)應(yīng)于多種語(yǔ)言的多個(gè)代碼樣本設(shè)計(jì)API時(shí)，在每一代碼樣本中傳遞的同一值可替換地被設(shè)置為對(duì)該聚集組件的默認(rèn)值?？啥ㄖ颇J(rèn)值可通過(guò)設(shè)置聚集組件上的一個(gè)或多個(gè)特性來(lái)改變。
許多開發(fā)者更喜歡通過(guò)試錯(cuò)法來(lái)書寫代碼，而不愿意在開始項(xiàng)目之前花時(shí)間讀文檔并完全弄懂特征區(qū)域。這對(duì)新手和偶爾為之的開發(fā)者，如使用VB寫代碼的開發(fā)者而言尤其如此。這些開發(fā)者經(jīng)常試圖使用API來(lái)試驗(yàn)以發(fā)現(xiàn)它起什么作用以及怎樣起作用，然后他們緩慢并遞增地調(diào)整其代碼直到該API實(shí)現(xiàn)達(dá)到其目標(biāo)。編輯并繼續(xù)方法的流行是該偏好的表現(xiàn)。
一些API設(shè)計(jì)將其本身給予“通過(guò)試驗(yàn)書寫代碼”，而一些則不這樣。當(dāng)使用通過(guò)試驗(yàn)書寫代碼方法時(shí)，有多個(gè)方面影響開發(fā)者可能具有的成功的級(jí)別。這些方面包括(i)為手邊的任務(wù)查找正確的API容易到何種程度；(ii)開始使用API，而無(wú)論它(最初)是否做了開發(fā)者希望它做或者不做的事情容易到何種程度；(iii)發(fā)現(xiàn)對(duì)API的定制點(diǎn)是什么容易到何種程度；(iv)發(fā)現(xiàn)對(duì)給定場(chǎng)景的正確的定制如何容易；以及(v)等等。
在描述的實(shí)現(xiàn)中，API被設(shè)計(jì)成需要很少的初始化(如最小的初始化量)，如果有的話。例如，可設(shè)計(jì)API使得具有單個(gè)參數(shù)的默認(rèn)的一個(gè)或多個(gè)構(gòu)造函數(shù)足夠開始使用一個(gè)類型。當(dāng)初始化必需時(shí)，不執(zhí)行初始化導(dǎo)致的異常清楚地解釋了需要完成和/或改變什么以移除或防止異常。例如，異?？梢?guī)定需要設(shè)置什么或哪些特性。
作為示例而非局限，簡(jiǎn)略的規(guī)則是最簡(jiǎn)單的構(gòu)造函數(shù)具有三個(gè)或更少的參數(shù)(上限為五)。另外，最簡(jiǎn)單的構(gòu)造函數(shù)應(yīng)當(dāng)避免復(fù)雜類型作為任一參數(shù)，其中，復(fù)雜類型可以是其它分解類型或聚集組件。另一簡(jiǎn)略的規(guī)則是最簡(jiǎn)單的構(gòu)造函數(shù)依賴于原語(yǔ)類型，如枚舉、串、整型等等。類型也可實(shí)現(xiàn)多個(gè)復(fù)雜構(gòu)造函數(shù)重載以支持多個(gè)復(fù)雜的場(chǎng)景。
簡(jiǎn)言之，API的可定制性可通過(guò)提供具有用于所有定制點(diǎn)的較佳默認(rèn)值的特性來(lái)簡(jiǎn)化。(然而，開發(fā)者在定制其場(chǎng)景時(shí)一般應(yīng)當(dāng)能夠向現(xiàn)有代碼添加新代碼；使用不同的API從無(wú)到有地重寫代碼應(yīng)當(dāng)是可任選的。)例如，系統(tǒng)消息通信隊(duì)列聚集組件在向構(gòu)造函數(shù)傳遞路徑串并調(diào)用發(fā)送方法之后啟用消息的發(fā)送。消息特性，如消息優(yōu)先級(jí)和加密算法可通過(guò)向核心場(chǎng)景添加代碼來(lái)定制。
自編對(duì)象模型自編對(duì)象模型(Self documenting object model)涉及設(shè)計(jì)一種API框架，其中開發(fā)者可察看其對(duì)象和成員來(lái)了解它們并能夠使用它們。例如，名字可基于一種類型如何期望被使用而非對(duì)許多開發(fā)者不希望學(xué)習(xí)的繼承層次的投入。簡(jiǎn)言之，自編對(duì)象模型方便了將為開發(fā)者的那些人的可發(fā)現(xiàn)性。
如上所述，一些開發(fā)者更喜歡通過(guò)試錯(cuò)法來(lái)書寫代碼，并經(jīng)常僅當(dāng)其直覺無(wú)法實(shí)現(xiàn)其預(yù)期的場(chǎng)景時(shí)才讀文檔。由此，自編對(duì)象模型應(yīng)當(dāng)避免需要開發(fā)者在每次想要執(zhí)行甚至簡(jiǎn)單的任務(wù)時(shí)讀文檔。以下呈現(xiàn)了幫助生成對(duì)描述的實(shí)現(xiàn)相對(duì)自編的直觀API的一組示例性原理和實(shí)踐。其任一一個(gè)或多個(gè)可以在給定的API和/或API設(shè)計(jì)實(shí)現(xiàn)中使用。
命名第一個(gè)指導(dǎo)原理是為用戶在大多數(shù)常見場(chǎng)景中需要使用(如例示)的類型保存簡(jiǎn)單且直觀的名字。設(shè)計(jì)者經(jīng)常“浪費(fèi)”抽象的最佳名字，大多數(shù)用戶不需要關(guān)心這些最佳名字。例如，如果期望是所有用戶在他們能夠開始使用API之前將必須理解該繼承層次，則將一個(gè)抽象基類命名為“File(文件)”，然后提供一種具體的類型“XYZFile”能起較好的作用。然而，如果用戶不理解該層次，則他們可能試圖使用，并且通常是不成功的第一樣?xùn)|西是“File”類型。更具體地，為以最前的核心場(chǎng)景為目標(biāo)的聚集組件保存了最常見或期望的名字，而較不常見或熟悉的名字在概念和抽象上使用。
第二個(gè)指導(dǎo)原理是使用清楚地規(guī)定每一方法完成什么以及每一類型和參數(shù)表示什么的描述性標(biāo)識(shí)符名字。例如，API設(shè)計(jì)者在選擇標(biāo)識(shí)符名字時(shí)不應(yīng)當(dāng)猶豫會(huì)變得相當(dāng)冗長(zhǎng)。例如，可以看到“EventLog.DeleteEventSource(string source，stringmachineName)”相當(dāng)冗長(zhǎng)，但是它可論證地具有一純的正可用性值。此外，類型和參數(shù)名字規(guī)定類型或參數(shù)表示了什么，而非它們完成了什么。方法名字規(guī)定方法完成了什么。當(dāng)然，精確的冗長(zhǎng)方法名字對(duì)具有簡(jiǎn)單且清楚語(yǔ)義的方法更容易，這是為何避免復(fù)雜語(yǔ)義是一種要遵循的較好的一般設(shè)計(jì)原理的原因。
指導(dǎo)設(shè)計(jì)實(shí)踐是將關(guān)于命名選擇的討論作為API規(guī)范的審閱和/或測(cè)試的一個(gè)重要部分包括在內(nèi)。示例性考慮和問題包括大多數(shù)場(chǎng)景開始的類型是什么？當(dāng)試圖實(shí)現(xiàn)給定場(chǎng)景時(shí)大多數(shù)人首先考慮的名字是什么？常見類型的名字是用戶首先考慮的名字嗎？例如，由于“File”是當(dāng)處理文件I/O場(chǎng)景時(shí)大多數(shù)人考慮的名字，因此用于訪問文件的聚集組件可以被命名為“File”。另外，審閱并測(cè)試了最常用類型及其參數(shù)的最常用方法。例如，熟悉該技術(shù)，但是不熟悉考慮中的具體API設(shè)計(jì)的任何人能快速、正確并容易地識(shí)別并調(diào)用那些方法嗎？異常如上所述，異?？煞奖阕跃嶢PI。換言之，API應(yīng)當(dāng)將用戶引導(dǎo)至下一要做的事物，并且異常能夠傳遞接下來(lái)所需要的事物并對(duì)其有益。例如，以下示例代碼用消息“The′FileName′property needs to be set before attempting to open the′FileObject′(在試圖打開‘FileObject’對(duì)象前需要設(shè)置‘FileName’特性)?！睊伋隽水惓！甐B‘例示Dim File As New FileObject()‘文件名未設(shè)置File.Open()強(qiáng)類型(Strong Typing)用于方便直觀API的另一指導(dǎo)原理是強(qiáng)類型。例如，調(diào)用“Customer.Name”比調(diào)用“Customer.Properties[′Name′]”更容易。此外，令這一“Name”特性將名字作為串返回比如果特性返回對(duì)象更有用。
有這些情況，期望具有基于串的訪問函數(shù)的特性包(property bag)、后綁定(late bind)調(diào)用以及其它非強(qiáng)類型API，但是它們被歸入稀有并且不是規(guī)則。此外，API設(shè)計(jì)者可為用戶在非強(qiáng)類型API層上執(zhí)行的更常見操作提供強(qiáng)類型助手。例如，消費(fèi)者類型可具有特性包，但是它可另外為類似于“名字”、“地址”等更常見的特性提供強(qiáng)類型API。
向簡(jiǎn)易性矢量化再一指導(dǎo)原理是為簡(jiǎn)易性而努力，尤其是對(duì)核心場(chǎng)景。標(biāo)準(zhǔn)設(shè)計(jì)方法針對(duì)生成為可維護(hù)性優(yōu)化的設(shè)計(jì)，如通過(guò)使用抽象。因此，現(xiàn)代設(shè)計(jì)方法生成許多抽象。一個(gè)問題是這類設(shè)計(jì)方法在結(jié)果設(shè)計(jì)的用戶將在開始實(shí)現(xiàn)甚至簡(jiǎn)單的場(chǎng)景之前變?yōu)樵撛O(shè)計(jì)中的專家的假設(shè)上操作。然而，這通常不是真實(shí)世界的情況。
在描述的實(shí)現(xiàn)中，至少對(duì)于簡(jiǎn)單的場(chǎng)景，API設(shè)計(jì)者確保對(duì)象模型層次足夠簡(jiǎn)單，使得它們能夠在不需理解整個(gè)特征區(qū)域如何相互適合或相互操作的情況下被使用。所得設(shè)計(jì)優(yōu)良的API可需要開發(fā)者理解所實(shí)現(xiàn)的核心場(chǎng)景，但是不需要對(duì)用于實(shí)現(xiàn)它的庫(kù)的設(shè)計(jì)有完全的理解。
一般地，核心場(chǎng)景API被指向或?qū)?yīng)于系統(tǒng)的物理或公知邏輯部件，而非抽象。對(duì)應(yīng)于抽象的類型通常在不理解該特征區(qū)域的所有部分如何相互適合并相互操作的情況下很難使用；因此當(dāng)需要交叉特征繼承時(shí)它們更相關(guān)。
另一指導(dǎo)實(shí)踐是當(dāng)設(shè)計(jì)內(nèi)部體系結(jié)構(gòu)以及某些分解類型時(shí)，但不是當(dāng)為核心或常見場(chǎng)景設(shè)計(jì)API(如具有聚集組件的API)時(shí)，使用標(biāo)準(zhǔn)設(shè)計(jì)方法(如，UML)。當(dāng)為核心場(chǎng)景設(shè)計(jì)聚集組件時(shí)，作為替換采用了場(chǎng)景驅(qū)動(dòng)設(shè)計(jì)以及原型化、可用性學(xué)習(xí)和迭代(如本發(fā)明上文所描述的)。
干凈的名字空間再一指導(dǎo)原理是(十分)少用的類型被放置在子名字空間中，以避免弄亂主名字空間。例如，以下兩組類型可以從其主名字空間中分離許可類型和設(shè)計(jì)類型。例如，許可類型可駐留在“.Permissions”子名字空間中，僅設(shè)計(jì)時(shí)(design-time-only)類型可駐留在“.Design”子名字空間中。
圖1-9的行動(dòng)、方面、特征和組件等在被劃分成多個(gè)塊的示圖中示出。然而，描述和/或示出圖1-9的順序、相互連接、相互關(guān)系、布局等不應(yīng)當(dāng)被解釋為局限，并且可以為設(shè)計(jì)API實(shí)現(xiàn)一個(gè)或多個(gè)系統(tǒng)、方法、設(shè)備、過(guò)程、媒體、API、裝置、方案等任一方式修改、組合、重排列、增加、省略等任意數(shù)量的塊。此外，盡管本發(fā)明的描述包括了對(duì)具體實(shí)現(xiàn)(以及圖10的示例性操作環(huán)境)的引用，示出和/或描述的實(shí)現(xiàn)可以任一合適的硬件、軟件、固件或其組合實(shí)現(xiàn)，并使用任一合適的軟件體系結(jié)構(gòu)、代碼語(yǔ)言、場(chǎng)景定義、可用性學(xué)習(xí)格式等來(lái)實(shí)現(xiàn)。
計(jì)算機(jī)或其它設(shè)備的示例性操作環(huán)境圖10示出了能夠?qū)崿F(xiàn)如本發(fā)明所描述的用于設(shè)計(jì)API的至少一個(gè)系統(tǒng)、設(shè)備、裝置、組件、方案、協(xié)議、途徑、方法、過(guò)程、媒體、API、其某一組合等。操作環(huán)境1000可以在下文描述的計(jì)算機(jī)和網(wǎng)絡(luò)體系結(jié)構(gòu)中使用。
示例性操作環(huán)境1000僅為環(huán)境的一個(gè)示例，并非建議對(duì)可應(yīng)用設(shè)備(包括計(jì)算機(jī)、網(wǎng)絡(luò)節(jié)點(diǎn)、娛樂設(shè)備、移動(dòng)器材、一般電子設(shè)備等)的使用或功能的范圍的局限。也不應(yīng)將操作環(huán)境1000(或其設(shè)備)解釋為對(duì)圖10所示的任一組件或其組合具有依賴或需求。
另外，設(shè)計(jì)API和/或從其起因的API可以使用眾多其它通用或?qū)Ｓ迷O(shè)備(包括計(jì)算系統(tǒng))環(huán)境或配置來(lái)操作。適合使用的眾所周知的設(shè)備、系統(tǒng)、環(huán)境和/或配置包括但不限于個(gè)人計(jì)算機(jī)、服務(wù)器計(jì)算機(jī)、薄客戶機(jī)、厚客戶機(jī)、個(gè)人數(shù)字助理(PDA)或移動(dòng)電話、表、手持式或膝上設(shè)備、多處理器系統(tǒng)、基于微處理器的系統(tǒng)、機(jī)頂盒、可編程消費(fèi)者電子設(shè)備、視頻游戲機(jī)、游戲控制臺(tái)、便攜式或手持式游戲單元、網(wǎng)絡(luò)PC、小型機(jī)、大型機(jī)、網(wǎng)絡(luò)節(jié)點(diǎn)、包括任一上述系統(tǒng)或設(shè)備的分布式或多處理計(jì)算環(huán)境、其某一組合等等。
API和/或從其起因的API的設(shè)計(jì)的實(shí)現(xiàn)可在處理器可執(zhí)行指令的一般上下文環(huán)境中描述。一般地，處理器可執(zhí)行指令包括例程、程序、模塊、協(xié)議、對(duì)象、接口、組件、數(shù)據(jù)結(jié)構(gòu)等等，執(zhí)行和/或啟用特定的任務(wù)和/或?qū)崿F(xiàn)特定的抽象數(shù)據(jù)類型。如本發(fā)明的某些實(shí)現(xiàn)所描述的，設(shè)計(jì)API和/或從其起因的API也可以在分布式處理環(huán)境中實(shí)踐和/或呈現(xiàn)，其中，任務(wù)由通過(guò)通信鏈路和/或網(wǎng)絡(luò)連接的遠(yuǎn)程連接的處理設(shè)備執(zhí)行。特別地但不是排他地在分布式計(jì)算環(huán)境中，處理器可執(zhí)行指令可以位于單獨(dú)的存儲(chǔ)媒質(zhì)上，由不同的處理器執(zhí)行，和/或通過(guò)傳輸媒質(zhì)傳播。
示例性操作環(huán)境1000包括計(jì)算機(jī)1002形式的通用計(jì)算裝置，它可包括具有計(jì)算/處理能力的任一(如電子)設(shè)備。計(jì)算機(jī)1002的組件包括但不限于，一個(gè)或多個(gè)處理器或處理單元1004、系統(tǒng)存儲(chǔ)器1006以及將包括處理器1004的各種系統(tǒng)組件耦合至系統(tǒng)存儲(chǔ)器1006的系統(tǒng)總線1008。
處理器1004不被從其形成的材料或其采用的處理機(jī)制所限制。例如，處理器1004可包括半導(dǎo)體和/或晶體管(如電子集成電路(IC))。在這一上下文中，處理器可執(zhí)行指令可以是電子可執(zhí)行指令?？蛇x地，處理器1004或用于其的機(jī)制，并且由此計(jì)算機(jī)1002或用于其的機(jī)制可包括但不限于，量子計(jì)算、光計(jì)算、機(jī)械計(jì)算(如使用毫微技術(shù))等等。
系統(tǒng)總線1008代表任一多種有線或無(wú)線總線結(jié)構(gòu)類型的一個(gè)或多個(gè)，包括存儲(chǔ)器總線或存儲(chǔ)器控制器、點(diǎn)對(duì)點(diǎn)連接、交換結(jié)構(gòu)、外圍總線、加速圖形端口、以及使用任一各種總線體系結(jié)構(gòu)的處理器或局部總線。作為示例，這類體系結(jié)構(gòu)可包括工業(yè)標(biāo)準(zhǔn)體系結(jié)構(gòu)(ISA)總線、微通道體系結(jié)構(gòu)(MCA)總線、增強(qiáng)ISA(EISA)總線、視頻電子技術(shù)標(biāo)準(zhǔn)協(xié)會(huì)(VESA)局部總線、外圍部件互連(PCI)總線，也稱為Mezzanine總線、其某一組合等等。
計(jì)算機(jī)1002通常包括各種處理器可訪問媒質(zhì)。這類媒質(zhì)可以是可由計(jì)算機(jī)1002或另一(如電子)設(shè)備訪問的任一可用媒質(zhì)，并包括易失和非易失、可移動(dòng)和不可移動(dòng)媒質(zhì)，以及存儲(chǔ)和傳輸媒質(zhì)。
系統(tǒng)存儲(chǔ)器1006包括易失存儲(chǔ)器形式的處理器可訪問存儲(chǔ)媒質(zhì)，如隨機(jī)存取存儲(chǔ)器(RAM)1040，和/或非易失存儲(chǔ)器形式的處理器可訪問存儲(chǔ)媒質(zhì)，如只讀存儲(chǔ)器(ROM)1012。基本輸入/輸出系統(tǒng)(BIOD)1014包含如在啟動(dòng)時(shí)幫助在計(jì)算機(jī)1002內(nèi)的元件之間傳輸信息的基本例程，通常儲(chǔ)存在ROM 1012中。RAM1010通常包含處理單元1004直接可訪問和/或當(dāng)前正在操作的數(shù)據(jù)和/或程序模塊/指令。
計(jì)算機(jī)1002也可包括其它可移動(dòng)/不可移動(dòng)和/或易失/非易失存儲(chǔ)媒質(zhì)。作為示例，圖10示出了對(duì)(通常)不可移動(dòng)、非易失磁媒質(zhì)(未單獨(dú)示出)進(jìn)行讀寫的硬盤驅(qū)動(dòng)器或硬盤驅(qū)動(dòng)陣列1016；對(duì)(通常)可移動(dòng)、非易失磁盤1020(如“軟盤”)進(jìn)行讀寫的磁盤驅(qū)動(dòng)器1018；以及對(duì)(通常)可移動(dòng)、非易失光盤1024，如CD、DVD或其它光媒質(zhì)進(jìn)行讀寫的光盤驅(qū)動(dòng)器1022。硬盤驅(qū)動(dòng)器1016、磁盤驅(qū)動(dòng)器1018和光盤驅(qū)動(dòng)器1022的每一個(gè)通過(guò)一個(gè)或多個(gè)存儲(chǔ)媒質(zhì)接口1026連接到系統(tǒng)總線1008。可選地，硬盤驅(qū)動(dòng)器1016、磁盤驅(qū)動(dòng)器1018和光盤驅(qū)動(dòng)器1022可以通過(guò)一個(gè)或多個(gè)其它的單獨(dú)或組合的接口(未示出)連接到系統(tǒng)總線1008。
盤驅(qū)動(dòng)器及其關(guān)聯(lián)的處理器可訪問媒質(zhì)為計(jì)算機(jī)1002提供了處理器可執(zhí)行指令，如數(shù)據(jù)結(jié)構(gòu)、程序模塊和其它數(shù)據(jù)的非易失存儲(chǔ)。盡管示例性計(jì)算機(jī)1002示出了硬盤1016、可移動(dòng)磁盤1020和可移動(dòng)光盤1024，可以理解，其它類型的處理器可訪問媒質(zhì)可儲(chǔ)存可由設(shè)備訪問的指令，設(shè)備如磁帶盒或其它磁存儲(chǔ)設(shè)備、閃存、光盤(CD)、數(shù)字多功能盤(DVD)或其它光存儲(chǔ)、RAM、ROM、電可擦除可編程只讀存儲(chǔ)器(EEPROM)等等。這類媒質(zhì)也可包括被稱為專用或硬布線的IC芯片。換言之，可以使用任一處理器可訪問媒質(zhì)來(lái)實(shí)現(xiàn)示例性操作環(huán)境1000的存儲(chǔ)媒質(zhì)。
多個(gè)程序模塊(或指令/代碼的其它單元或組，包括基于其的API框架和/或?qū)ο?可儲(chǔ)存在硬盤1016、磁盤1020、光盤1024、ROM 1012和/或RAM 1040中，作為一般示例包括，操作系統(tǒng)1028、一個(gè)或多個(gè)應(yīng)用程序1030、其它程序模塊1032和程序數(shù)據(jù)1034。
用戶可以通過(guò)輸入設(shè)備，如鍵盤1036和定位設(shè)備1038(如，“鼠標(biāo)”)向計(jì)算機(jī)1002輸入命令和信息。其它輸入設(shè)備1040(未具體示出)可包括麥克風(fēng)、操縱桿、游戲墊、圓盤式衛(wèi)星天線、串行端口、掃描儀和/或其類似物。這些和其它輸入設(shè)備通過(guò)耦合至系統(tǒng)總線1008的輸入/輸出接口1042連接至處理單元1004。然而，輸入設(shè)備和/或輸出設(shè)備可替換地通過(guò)其它接口和總線結(jié)構(gòu)連接，如并行端口、游戲端口、通用串行總線(USB)和紅外端口、IEEE 1394(“火線”)接口、IEEE 802.11無(wú)線接口、Bluetooth(藍(lán)牙)無(wú)線接口等。
監(jiān)視器/察看屏幕1044或其它類型的顯示設(shè)備也通過(guò)接口，如視頻適配器1046連接至系統(tǒng)總線1008。視頻適配器1046(或另一組件)可以是或可包括用于處理圖形密集型計(jì)算并用戶處理需要的顯示需求的圖形卡。通常，圖形卡包括圖形處理單元(GPU)、視頻RAM(VRAM)等等，以方便圖形的迅速顯示和圖形操作的性能。除監(jiān)視器1044之外，其它輸出外圍設(shè)備可包括諸如揚(yáng)聲器(未示出)和打印機(jī)1048等組件，通過(guò)輸入/輸出接口1042連接至計(jì)算機(jī)1002。
計(jì)算機(jī)420可以在使用到一個(gè)或多個(gè)遠(yuǎn)程計(jì)算機(jī)，如遠(yuǎn)程計(jì)算裝置1050的邏輯連接的網(wǎng)絡(luò)化環(huán)境中操作。作為示例，遠(yuǎn)程計(jì)算裝置1050可以是個(gè)人計(jì)算機(jī)、便攜式計(jì)算機(jī)(如，膝上計(jì)算機(jī)、圖形輸入板計(jì)算機(jī)、PDA、移動(dòng)站等等)、掌上或袖珍計(jì)算機(jī)、表、游戲設(shè)備、服務(wù)器、路由器、網(wǎng)絡(luò)計(jì)算機(jī)、對(duì)等設(shè)備、另一網(wǎng)絡(luò)節(jié)點(diǎn)或如上列出的另一設(shè)備類型等等。然而，示出遠(yuǎn)程計(jì)算裝置1050為便攜式計(jì)算機(jī)，可包括許多或所有此處相對(duì)計(jì)算機(jī)1002所描述的元件和特征。
計(jì)算機(jī)1002和遠(yuǎn)程計(jì)算機(jī)1050之間的邏輯連接被描述為局域網(wǎng)(LAN)1052和一般廣域網(wǎng)(WAN)1054。這類網(wǎng)絡(luò)環(huán)境常見于辦公室、企業(yè)范圍計(jì)算機(jī)網(wǎng)絡(luò)、內(nèi)聯(lián)網(wǎng)、因特網(wǎng)、固定和移動(dòng)電話網(wǎng)絡(luò)、特別和基礎(chǔ)結(jié)構(gòu)無(wú)線網(wǎng)絡(luò)、其它無(wú)線網(wǎng)絡(luò)、游戲網(wǎng)絡(luò)、其某一組合等等。這類網(wǎng)絡(luò)和通信連接是傳輸媒質(zhì)的示例。
當(dāng)在LAN網(wǎng)絡(luò)環(huán)境中實(shí)現(xiàn)時(shí)，計(jì)算機(jī)1002通常通過(guò)網(wǎng)絡(luò)接口或適配器1056連接至LAN 1052。當(dāng)在WAN網(wǎng)絡(luò)環(huán)境中實(shí)現(xiàn)時(shí)，計(jì)算機(jī)1002通常包括調(diào)制解調(diào)器454或其它裝置，用于通過(guò)WAN 1054建立通信。調(diào)制解調(diào)器1058可以對(duì)計(jì)算機(jī)是內(nèi)置或外置的，通過(guò)輸入/輸出接口1042或任一其它合適的機(jī)制連接至系統(tǒng)總線1008?？梢岳斫?，示出的網(wǎng)絡(luò)連接是示例性的，也可以使用在計(jì)算機(jī)1002和1050之間建立通信鏈路的其它裝置。
在網(wǎng)絡(luò)化環(huán)境中，如使用操作環(huán)境1000所示出的，描述的與計(jì)算機(jī)1002相關(guān)的程序模塊或其它指令，或其部分可完全或部分地儲(chǔ)存在遠(yuǎn)程媒質(zhì)存儲(chǔ)設(shè)備中。作為示例，遠(yuǎn)程應(yīng)用程序1060駐留在遠(yuǎn)程計(jì)算機(jī)1050的存儲(chǔ)器組件上，但是可由計(jì)算機(jī)1002使用或通過(guò)其訪問。同樣，為說(shuō)明目的，此處示出應(yīng)用程序1030和其它處理器可執(zhí)行指令，如操作系統(tǒng)1028為離散的塊，但是可以認(rèn)識(shí)到，這類程序、組件和其它指令在不同的時(shí)刻駐留在計(jì)算裝置1002(和/或遠(yuǎn)程計(jì)算裝置1050)的不同存儲(chǔ)組件中，并由計(jì)算機(jī)1002的處理器1004(和/或遠(yuǎn)程計(jì)算裝置1050的處理器)執(zhí)行。
盡管以對(duì)結(jié)構(gòu)、邏輯、算法、功能和基于行動(dòng)的特征的語(yǔ)言和/或示圖描述了系統(tǒng)、媒質(zhì)、設(shè)備、方法、過(guò)程、裝置、技術(shù)、API、模式、途徑。程序、方案和其它實(shí)現(xiàn)，可以理解，所附權(quán)利要求書中定義的本發(fā)明不必局限在所描述的具體特征或示圖上。相反，解釋了具體的特征和示圖作為實(shí)現(xiàn)本發(fā)明的示例性形式。
權(quán)利要求
1.一種設(shè)計(jì)應(yīng)用編程接口(API)的方法，其特征在于，所述方法包括為核心場(chǎng)景準(zhǔn)備多個(gè)代碼樣本，所述多個(gè)代碼樣本的每一相應(yīng)的代碼樣本對(duì)應(yīng)于多個(gè)編程語(yǔ)言的一相應(yīng)的編程語(yǔ)言；以及響應(yīng)于所述多個(gè)代碼樣本，從所述核心場(chǎng)景衍生所述API。
2.如權(quán)利要求1所述的方法，其特征在于，它還包括由API設(shè)計(jì)者確定所衍生的API是否太過(guò)復(fù)雜。
3.如權(quán)利要求2所述的方法，其特征在于，它還包括如果所衍生的API被確定為太過(guò)復(fù)雜，則由所述API設(shè)計(jì)者提煉所衍生的API以生成提煉的API。
4.如權(quán)利要求3所述的方法，其特征在于，它還包括由所述API設(shè)計(jì)者確定所提煉的API是否太過(guò)復(fù)雜。
5.如權(quán)利要求1所述的方法，其特征在于，它還包括使用多個(gè)開發(fā)者在所述API上執(zhí)行一個(gè)或多個(gè)可用性學(xué)習(xí)。
6.如權(quán)利要求5所述的方法，其特征在于，所述執(zhí)行包括使用所述多個(gè)開發(fā)者在所述API上執(zhí)行所述一個(gè)或多個(gè)可用性學(xué)習(xí)，其中，所述多個(gè)開發(fā)者對(duì)所述多個(gè)編程語(yǔ)言是典型的。
7.如權(quán)利要求5所述的方法，其特征在于，它還包括斷定所述多個(gè)開發(fā)者是否能夠在沒有重大問題的情況下使用所述API。
8.如權(quán)利要求7所述的方法，其特征在于，它還包括如果所述多個(gè)開發(fā)者不被斷定為能夠在沒有重大問題的情況下使用所述API，則修訂所述API。
9.如權(quán)利要求8所述的方法，其特征在于，所述修訂包括基于來(lái)自所述一個(gè)或多個(gè)可用性學(xué)習(xí)的至少一個(gè)經(jīng)驗(yàn)修訂所述API。
10.如權(quán)利要求1所述的方法，其特征在于，所述衍生包括衍生所述API以支持分別對(duì)應(yīng)于所述多個(gè)編程語(yǔ)言的所述多個(gè)代碼樣本。
11.如權(quán)利要求1所述的方法，其特征在于，所述衍生包括從所述多個(gè)代碼樣本收集語(yǔ)言專用命令；以及將所述語(yǔ)言專用命令結(jié)合進(jìn)所述API中。
12.如權(quán)利要求1所述的方法，其特征在于，所述衍生包括從所述多個(gè)代碼樣本收集語(yǔ)言啟示的開發(fā)者期望；以及將所述語(yǔ)言啟發(fā)的開發(fā)者期望結(jié)合進(jìn)所述API中。
13.如權(quán)利要求1所述的方法，其特征在于，所述衍生包括從所述多個(gè)代碼樣本收集通用性；以及將所述通用性結(jié)合進(jìn)所述API中。
14.如權(quán)利要求1所述的方法，其特征在于，所述衍生包括衍生所述API以具有將多個(gè)低層分解類型捆綁在一起以支持所述核心場(chǎng)景的聚集組件。
15.一種設(shè)計(jì)應(yīng)用編程接口(API)的方法，其特征在于，所述方法包括為特征區(qū)域選擇核心場(chǎng)景；為所述核心場(chǎng)景書寫至少一個(gè)代碼樣本；以及響應(yīng)于所述至少一個(gè)代碼樣本，衍生用于所述核心場(chǎng)景的API。
16.如權(quán)利要求15所述的方法，其特征在于，所述選擇包括為所述特征區(qū)域選擇多個(gè)核心場(chǎng)景。
17.如權(quán)利要求16所述的方法，其特征在于，它還包括對(duì)為所述特征區(qū)域所選擇的多個(gè)核心場(chǎng)景的每一核心場(chǎng)景重復(fù)所述書寫和所述衍生。
18.如權(quán)利要求15所述的方法，其特征在于，所述書寫包括為所述核心場(chǎng)景書寫多個(gè)代碼樣本，所述多個(gè)代碼樣本的每一相應(yīng)的代碼樣本對(duì)應(yīng)于多個(gè)編程語(yǔ)言的一相應(yīng)的編程語(yǔ)言。
19.如權(quán)利要求18所述的方法，其特征在于，所述衍生包括響應(yīng)于所述多個(gè)代碼樣本衍生用于所述核心場(chǎng)景的API。
20.如權(quán)利要求15所述的方法，其特征在于，它還包括使用多個(gè)開發(fā)者在所述API上執(zhí)行一個(gè)或多個(gè)可用性學(xué)習(xí)；斷定所述多個(gè)開發(fā)者是否能夠在沒有重大問題的情況下使用所述API；以及如果所述多個(gè)開發(fā)者不被斷定為能夠在沒有重大問題的情況下使用所述API，則修訂所述API。
21.如權(quán)利要求20所述的方法，其特征在于，所述修訂包括基于來(lái)自所述一個(gè)或多個(gè)可用性學(xué)習(xí)的至少一個(gè)經(jīng)驗(yàn)修訂所述API以生成修訂的API。
22.如權(quán)利要求21所述的方法，其特征在于，它還包括對(duì)所述修訂的API重復(fù)所述執(zhí)行和所述斷定。
23.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括通過(guò)生成一包括一聚集組件和多個(gè)基礎(chǔ)分解類型的雙層API，衍生所述API以支持為所述核心場(chǎng)景書寫的至少一個(gè)代碼樣本。
24.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括從所述至少一個(gè)代碼樣本收集一個(gè)或多個(gè)語(yǔ)言專用命令；以及將所述一個(gè)或多個(gè)語(yǔ)言專用命令結(jié)合進(jìn)所述API中。
25.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括如果一特定的分解類型的所有成員由與所述核心場(chǎng)景關(guān)聯(lián)的聚集組件展現(xiàn)，將所述特定的分解類型封裝到所述聚集組件中。
26.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括如果一特定的分解類型對(duì)其它組件類型是獨(dú)立地不感興趣的，則將所述特定的分解類型封裝到與所述核心場(chǎng)景關(guān)聯(lián)的聚集組件中。
27.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括如果一特定類型的至少一個(gè)成員不由與所述核心場(chǎng)景關(guān)聯(lián)的聚集組件展現(xiàn)，則從所述聚集組件展現(xiàn)所述特定的分解類型。
28.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括如果一特定的分解類型可以由另一組件類型獨(dú)立于與所述核心場(chǎng)景關(guān)聯(lián)的聚集組件有利使用，則從所述聚集組件展現(xiàn)所述特定的分解類型。
29.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括生成一包括以相對(duì)高度抽象為目標(biāo)的組件類型和以相對(duì)低度抽象為目標(biāo)的組件類型的雙層框架。
30.如權(quán)利要求29所述的方法，其特征在于，以相對(duì)高度抽象為目標(biāo)的所述組件類型被定向到核心場(chǎng)景。
31.如權(quán)利要求29所述的方法，其特征在于，以相對(duì)低度抽象為目標(biāo)的所述組件類型與以相對(duì)高度抽象為目標(biāo)的所述組件類型相比，向開發(fā)者提供了相對(duì)更大數(shù)量的控制。
32.如權(quán)利要求15所述的方法，其特征在于，所述衍生包括衍生所述API以令開發(fā)者能夠?yàn)樗龊诵膱?chǎng)景實(shí)現(xiàn)一創(chuàng)建-設(shè)置-調(diào)用用法模式。
33.如權(quán)利要求32所述的方法，其特征在于，所述衍生包括用預(yù)選擇的適合所述核心場(chǎng)景的參數(shù)產(chǎn)生所述API。
34.一種設(shè)計(jì)應(yīng)用編程接口(API)的方法，其特征在于，它包括響應(yīng)于對(duì)場(chǎng)景書寫的至少一個(gè)代碼樣本，衍生用于所述場(chǎng)景的API；使用多個(gè)開發(fā)者在所述API上執(zhí)行一個(gè)或多個(gè)可用性學(xué)習(xí)；以及基于所述一個(gè)或多個(gè)可用性學(xué)習(xí)修訂所述API。
35.如權(quán)利要求34所述的方法，其特征在于，它還包括對(duì)所述場(chǎng)景書寫多個(gè)代碼樣本，所述多個(gè)代碼樣本的每一相應(yīng)的代碼樣本對(duì)應(yīng)于多個(gè)編程語(yǔ)言的一相應(yīng)的編程語(yǔ)言；其中，所述衍生包括響應(yīng)于所述多個(gè)代碼樣本，衍生用于所述場(chǎng)景的API。
36.如權(quán)利要求34所述的方法，其特征在于，它還包括，在所述API上執(zhí)行一個(gè)或多個(gè)可用性學(xué)習(xí)之前由API設(shè)計(jì)者確定所衍生的API是否太過(guò)復(fù)雜；如果所衍生的API被確定為太過(guò)復(fù)雜，則由所述API設(shè)計(jì)者提煉所衍生的API以生成提煉的API；以及由所述API設(shè)計(jì)者確定所提煉的API是否太過(guò)復(fù)雜。
37.如權(quán)利要求34所述的方法，其特征在于，它還包括斷定所述多個(gè)開發(fā)者是否能在沒有重大問題的情況下使用所述API；以及當(dāng)所述多個(gè)開發(fā)者不被斷定為能夠在沒有重大問題的情況下使用所述API，則實(shí)現(xiàn)所述修訂；其中，所述修訂包括基于來(lái)自所述一個(gè)或多個(gè)可用性學(xué)習(xí)的至少一個(gè)經(jīng)驗(yàn)修訂所述API以生成修訂的API。
38.如權(quán)利要求37所述的方法，其特征在于，它還包括對(duì)所述修訂的API至少重復(fù)所述執(zhí)行和所述斷定。
39.如權(quán)利要求37所述的方法，其特征在于，所述斷定包括對(duì)于至少一個(gè)目標(biāo)開發(fā)者組的可用性的期望級(jí)別，斷定所述多個(gè)開發(fā)者是否能在沒有重大問題的情況下使用所述API，其中，所述可用性的期望級(jí)別包括對(duì)于以下的考慮(i)由多個(gè)開發(fā)者對(duì)詳細(xì)的API文檔的頻繁和/或廣泛參考，(ii)所述多個(gè)開發(fā)者的大多數(shù)實(shí)現(xiàn)所述場(chǎng)景的失敗，以及(iii)所述多個(gè)開發(fā)者是否采用與API設(shè)計(jì)者所期望的顯著不同的方法。
40.如權(quán)利要求34所述的方法，其特征在于，它還包括為特征區(qū)域選擇多個(gè)核心場(chǎng)景；對(duì)所述多個(gè)核心場(chǎng)景的每一核心場(chǎng)景，重復(fù)所述衍生、所述執(zhí)行和所述修訂。
41.如權(quán)利要求40所述的方法，其特征在于，所述衍生包括對(duì)所述多個(gè)核心場(chǎng)景的每一核心場(chǎng)景生成一聚集組件。
42.如權(quán)利要求34所述的方法，其特征在于，所述衍生包括生成一與多個(gè)分解類型的每一相應(yīng)的分解類型具有相應(yīng)的關(guān)系的聚集組件。
43.如權(quán)利要求42所述的方法，其特征在于，所述生成包括生成所述聚集組件以支持為其書寫所述至少一個(gè)代碼樣本的所述場(chǎng)景。
44.如權(quán)利要求42所述的方法，其特征在于，所述生成包括生成所述聚集組件以與所述多個(gè)分解類型中的至少一個(gè)分解類型有展現(xiàn)關(guān)系，并與所述多個(gè)分解類型中的至少一個(gè)其它分解類型有封裝關(guān)系。
45.如權(quán)利要求44所述的方法，其特征在于，與所述聚集組件有封裝關(guān)系的所述多個(gè)分解類型中的至少一個(gè)其它類型可由所述聚集組件傳送，用于與另一組件類型的直接交互。
46.如權(quán)利要求42所述的方法，其特征在于，所述多個(gè)分解類型使用面向?qū)ο蟮募夹g(shù)來(lái)設(shè)計(jì)。
47.一種設(shè)計(jì)應(yīng)用編程接口(API)的方法，其特征在于，所述方法包括為核心場(chǎng)景準(zhǔn)備多個(gè)代碼樣本，所述多個(gè)代碼樣本的每一相應(yīng)的代碼樣本對(duì)應(yīng)于多個(gè)編程語(yǔ)言的一相應(yīng)的編程語(yǔ)言；響應(yīng)于所述多個(gè)代碼樣本，衍生用于所述核心場(chǎng)景的API；使用多個(gè)開發(fā)者在所述API上執(zhí)行一個(gè)或多個(gè)可用性學(xué)習(xí)；以及基于所述一個(gè)或多個(gè)可用性學(xué)習(xí)修訂所述API。
48.一種設(shè)計(jì)應(yīng)用編程接口(API)的方法，其特征在于，所述方法包括為場(chǎng)景書寫至少一個(gè)代碼樣本；以及響應(yīng)于所述至少一個(gè)代碼樣本，衍生用于所述場(chǎng)景的API，所述API包括(i)一適用于方便所述場(chǎng)景的實(shí)現(xiàn)的聚集組件，以及(ii)為所述聚集組件提供基礎(chǔ)功能的多個(gè)分解類型，所述API啟用了從在較簡(jiǎn)單的情況下使用所述聚集組件到在愈加復(fù)雜的情況下使用所述多個(gè)分解類型的一個(gè)遞增部分的逐步漸進(jìn)。
49.一種設(shè)計(jì)應(yīng)用編程接口(API)的方法，其特征在于，所述方法包括衍生至少一個(gè)聚集組件以支持用于至少一個(gè)場(chǎng)景的至少一個(gè)代碼樣本；確定對(duì)所述至少一個(gè)場(chǎng)景的另外的需求；判定所述另外的需求是否能在不向所述至少一個(gè)場(chǎng)景添加不適當(dāng)?shù)膹?fù)雜度的情況下被添加到所述至少一個(gè)聚集組件中；以及如果不能，則響應(yīng)于所述判定，定義多個(gè)分解類型。
50.如權(quán)利要求49所述的方法，其特征在于，它還包括如果是，則提煉所述至少一個(gè)聚集組件以結(jié)合所述另外的需求。
51.如權(quán)利要求49所述的方法，其特征在于，它還包括為特征區(qū)域選擇多個(gè)核心場(chǎng)景，所述多個(gè)核心場(chǎng)景包括至少一個(gè)場(chǎng)景；以及為所述多個(gè)核心場(chǎng)景書寫示出較佳的代碼行的多個(gè)代碼樣本，所述多個(gè)代碼樣本包括所述至少一個(gè)代碼樣本；其中，所述衍生包括衍生包括所述至少一個(gè)聚集組件的多個(gè)聚集組件，以支持用于所述多個(gè)核心場(chǎng)景的所述多個(gè)代碼樣本。
52.如權(quán)利要求49所述的方法，其特征在于，所述衍生包括用適當(dāng)?shù)姆椒ā⒛J(rèn)值和抽象衍生所述至少一個(gè)聚集組件，以支持用于所述至少一個(gè)場(chǎng)景的所述至少一個(gè)代碼樣本。
53.如權(quán)利要求49所述的方法，其特征在于，它還包括依照所述至少一個(gè)衍生的聚集組件提煉所述至少一個(gè)代碼樣本；以及就簡(jiǎn)易性評(píng)估所提煉的至少一個(gè)代碼樣本；以及如果在所述評(píng)估中所提煉的至少一個(gè)代碼樣本尚不足夠簡(jiǎn)單，重復(fù)所述衍生。
54.如權(quán)利要求49所述的方法，其特征在于，所述確定包括確定對(duì)所述至少一個(gè)場(chǎng)景的另外的需求，其中，所述另外的需求包括另外的場(chǎng)景、另外的用法以及與其它組件類型的另外的交互。
55.如權(quán)利要求49所述的方法，其特征在于，所述判定包括考慮向所述至少一個(gè)聚集組件添加所述另外的需求是否阻礙了一創(chuàng)建-設(shè)置-調(diào)用用法模式。
56.如權(quán)利要求49所述的方法，其特征在于，所述定義包括響應(yīng)于所述判定，用一組完整功能的理想分解定義所述多個(gè)分解類型。
57.如權(quán)利要求49所述的方法，其特征在于，所述定義包括響應(yīng)于所述判定，使用一個(gè)或多個(gè)面向?qū)ο蟮姆椒ǘx所述多個(gè)分解類型。
58.如權(quán)利要求49所述的方法，其特征在于，它還包括確定所述至少一個(gè)聚集組件是否封裝或展現(xiàn)所述多個(gè)分解類型的每一分解類型的功能。
59.如權(quán)利要求49所述的方法，其特征在于，它還包括提煉所述多個(gè)分解類型以支持所述至少一個(gè)聚集組件和所述另外的需求。
全文摘要
用于設(shè)計(jì)應(yīng)用編程接口(API)的第一示例性方法實(shí)現(xiàn)包括為核心場(chǎng)景準(zhǔn)備多個(gè)代碼樣本，該多個(gè)代碼樣本的每一相應(yīng)的代碼樣本對(duì)應(yīng)于多個(gè)編程語(yǔ)言的一相應(yīng)的編程語(yǔ)言；以及響應(yīng)于該多個(gè)代碼樣本，從該核心場(chǎng)景衍生API。用于設(shè)計(jì)API的第二示例性方法包括為特征區(qū)域選擇核心場(chǎng)景；為該核心場(chǎng)景書寫至少一個(gè)代碼樣本；以及響應(yīng)于該至少一個(gè)代碼樣本衍生用于該核心場(chǎng)景的API。用于設(shè)計(jì)API的第三示例性方法包括響應(yīng)于對(duì)核心場(chǎng)景書寫的至少一個(gè)代碼樣本衍生用于該核心場(chǎng)景的API；使用多個(gè)開發(fā)者在該API上執(zhí)行一個(gè)或多個(gè)可用性學(xué)習(xí)；以及基于該一個(gè)或多個(gè)可用性學(xué)習(xí)修訂該API。
文檔編號(hào)G06F9/44GK1609796SQ20041008264
公開日2005年4月27日 申請(qǐng)日期2004年9月23日 優(yōu)先權(quán)日2003年10月23日
發(fā)明者A·J·摩爾, B·M·阿布拉姆斯, C·L·安德森, K·J·克瓦里納, M·J·皮佐, R·A·布里罕姆 申請(qǐng)人:微軟公司