首頁猿問為什么不建議使用傘形框架？

為什么不建議使用傘形框架？

Swift

慕森王 2019-12-13 15:10:28

我想分發(fā)框架A。框架A依賴于框架B。我希望框架的用戶只需要包括框架A，但仍然可以通過編程方式訪問框架B。Apple始終使用“傘框架”（Umbrella Frameworks）的概念來執(zhí)行此操作，但是文檔中包含以下主題：不要?jiǎng)?chuàng)建傘框架盡管可以使用Xcode創(chuàng)建傘形框架，但是對(duì)于大多數(shù)開發(fā)人員而言，這樣做是不必要的，因此不建議這樣做。蘋果使用傘形框架掩蓋了操作系統(tǒng)中庫之間的某些相互依賴關(guān)系。在幾乎所有情況下，您都應(yīng)該可以將代碼包含在單個(gè)標(biāo)準(zhǔn)框架包中。另外，如果您的代碼具有足夠的模塊化，則可以創(chuàng)建多個(gè)框架，但是在那種情況下，模塊之間的依賴關(guān)系將是最小的或不存在，因此不應(yīng)保證為它們創(chuàng)建保護(hù)傘。為什么不鼓勵(lì)這種方法？是什么讓它成為解決Apple相互依賴框架問題而不是我的框架的好解決方案？

查看完整描述

3 回答

瀟湘沐

TA貢獻(xiàn)1816條經(jīng)驗(yàn) 獲得超6個(gè)贊

僅當(dāng)您是所有涉及的框架的唯一分發(fā)者時(shí)，傘框架才有意義，并且您將所有框架打包為一個(gè)單獨(dú)的版本包，將一起升級(jí)。如果那是您的情況，那很好，但這是一種非常不尋常的情況。在可可開發(fā)世界中，除了蘋果公司以外的任何人都處于這種情況是極為不尋常的。

首先，只有您是給定框架的唯一分發(fā)者，傘式框架才有意義。例如，假設(shè)您想將libcurl作為傘形框架的一部分?，F(xiàn)在，其他一些打包程序也希望將libcurl作為其傘形框架的一部分。現(xiàn)在，我們發(fā)生了鏈接時(shí)沖突，這可能導(dǎo)致鏈接錯(cuò)誤或更糟的，未定義的運(yùn)行時(shí)行為。我自己追逐了這些。他們非常不愉快。避免這種情況的唯一方法是每個(gè)框架/庫只有一個(gè)版本。傘框架鼓勵(lì)相反。

即使您只是將自己的代碼分解成多個(gè)子部分，這也意味著其他供應(yīng)商可能會(huì)在自己的傘形框架中使用子框架，從而導(dǎo)致同樣的問題。請(qǐng)記住，如果您說作為第三方使用傘式框架是可以的，那么其他供應(yīng)商也可以。

第二點(diǎn)，僅當(dāng)您控制所有子框架的版本控制時(shí)，傘式框架才有意義。在我的經(jīng)驗(yàn)中，嘗試修補(bǔ)一組相互依賴的框架幾乎總是一個(gè)災(zāi)難。

操作系統(tǒng)供應(yīng)商由于其系統(tǒng)的規(guī)模和普遍性而出現(xiàn)了異常情況。在一個(gè)范圍內(nèi)有意義的事情通常在另一個(gè)范圍內(nèi)沒有意義。NSResponder對(duì)此完全正確。當(dāng)您提供一個(gè)完整的，成千上萬的軟件包環(huán)境時(shí)，這些取舍是不同的，這是為平臺(tái)編寫的每個(gè)程序的基礎(chǔ)。但是，即使蘋果公司也只有少數(shù)大型傘式框架，它們始終是它們提供和控制其版本的庫的包裝。這主要是為了簡(jiǎn)化開發(fā)人員的工作，否則他們將不得不追逐數(shù)十個(gè)庫和框架來進(jìn)行編譯。沒有第三方有這種情況，因此很少有第三方需要此解決方案。

我在這里的大部分討論是針對(duì)OS X的。在iOS上，這不是第三方的問題。由于肯定會(huì)發(fā)生沖突，因此靜態(tài)庫絕不能鏈接其他靜態(tài)庫。

從理論上講，我在這里討論的大多數(shù)問題從根本上限制了鏈接程序的技術(shù)限制。鏈接器沒有管理多種版本庫的好方法，因此沖突是一個(gè)嚴(yán)重的問題。.NET程序集試圖為此提供更多的靈活性。我對(duì).NET開發(fā)還不太熟悉，無法說出它是否成功。我在大型多組件系統(tǒng)上的經(jīng)驗(yàn)是，對(duì)于大多數(shù)問題而言，更簡(jiǎn)單，更不靈活的解決方案是最好的。（但是，那草總是更綠了...。）

反對(duì) 回復(fù) 2019-12-14