我想分發(fā)框架A?？蚣蹵依賴于框架B。我希望框架的用戶只需要包括框架A，但仍然可以通過編程方式訪問框架B。Apple始終使用“傘框架”（Umbrella Frameworks）的概念來執(zhí)行此操作，但是文檔中包含以下主題：不要創(chuàng)建傘框架盡管可以使用Xcode創(chuàng)建傘形框架，但是對于大多數(shù)開發(fā)人員而言，這樣做是不必要的，因此不建議這樣做。蘋果使用傘形框架掩蓋了操作系統(tǒng)中庫之間的某些相互依賴關系。在幾乎所有情況下，您都應該可以將代碼包含在單個標準框架包中。另外，如果您的代碼具有足夠的模塊化，則可以創(chuàng)建多個框架，但是在那種情況下，模塊之間的依賴關系將是最小的或不存在，因此不應保證為它們創(chuàng)建保護傘。為什么不鼓勵這種方法？是什么讓它成為解決Apple相互依賴框架問題而不是我的框架的好解決方案？
3 回答
瀟湘沐
TA貢獻1816條經(jīng)驗 獲得超6個贊
僅當您是所有涉及的框架的唯一分發(fā)者時，傘框架才有意義，并且您將所有框架打包為一個單獨的版本包，將一起升級。如果那是您的情況，那很好，但這是一種非常不尋常的情況。在可可開發(fā)世界中，除了蘋果公司以外的任何人都處于這種情況是極為不尋常的。
首先，只有您是給定框架的唯一分發(fā)者，傘式框架才有意義。例如，假設您想將libcurl作為傘形框架的一部分?，F(xiàn)在，其他一些打包程序也希望將libcurl作為其傘形框架的一部分?，F(xiàn)在，我們發(fā)生了鏈接時沖突，這可能導致鏈接錯誤或更糟的，未定義的運行時行為。我自己追逐了這些。他們非常不愉快。避免這種情況的唯一方法是每個框架/庫只有一個版本。傘框架鼓勵相反。
即使您只是將自己的代碼分解成多個子部分，這也意味著其他供應商可能會在自己的傘形框架中使用子框架，從而導致同樣的問題。請記住，如果您說作為第三方使用傘式框架是可以的，那么其他供應商也可以。
第二點，僅當您控制所有子框架的版本控制時，傘式框架才有意義。在我的經(jīng)驗中，嘗試修補一組相互依賴的框架幾乎總是一個災難。
操作系統(tǒng)供應商由于其系統(tǒng)的規(guī)模和普遍性而出現(xiàn)了異常情況。在一個范圍內(nèi)有意義的事情通常在另一個范圍內(nèi)沒有意義。NSResponder對此完全正確。當您提供一個完整的，成千上萬的軟件包環(huán)境時，這些取舍是不同的，這是為平臺編寫的每個程序的基礎。但是，即使蘋果公司也只有少數(shù)大型傘式框架，它們始終是它們提供和控制其版本的庫的包裝。這主要是為了簡化開發(fā)人員的工作，否則他們將不得不追逐數(shù)十個庫和框架來進行編譯。沒有第三方有這種情況，因此很少有第三方需要此解決方案。
我在這里的大部分討論是針對OS X的。在iOS上，這不是第三方的問題。由于肯定會發(fā)生沖突，因此靜態(tài)庫絕不能鏈接其他靜態(tài)庫。
從理論上講，我在這里討論的大多數(shù)問題從根本上限制了鏈接程序的技術限制。鏈接器沒有管理多種版本庫的好方法，因此沖突是一個嚴重的問題。.NET程序集試圖為此提供更多的靈活性。我對.NET開發(fā)還不太熟悉，無法說出它是否成功。我在大型多組件系統(tǒng)上的經(jīng)驗是，對于大多數(shù)問題而言，更簡單，更不靈活的解決方案是最好的。（但是，那草總是更綠了...。）
墨色風雨
TA貢獻1853條經(jīng)驗 獲得超6個贊
以蘋果公司為例，他們提供了大量的代碼，而這些子框架通常需要單獨修訂。如果要交付幾份框架，則可能要繼續(xù)制作一個傘形框架。如果沒有，您可能不需要麻煩。
- 3 回答
- 0 關注
- 452 瀏覽
添加回答
舉報
0/150
提交
取消