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