約翰給出了很好的建議,但這裏有更多的背景,關於whys,因爲和例外。
避免將標題導入標題有兩個目的:改進增量構建時間和避免循環依賴。如果導入A.h
到B.h
並導入B.h
爲C.h
,然後每次在A.h
改變任何東西的時候,你必須重新編譯C.m
,即使C.m
是沒有使用任何的A.h
定義的東西。這可能會導致非常可怕和不必要的構建流失,特別是如果您的頭文件經常更改(如在開發的早期階段常見)。
第一個目標值得稱讚,但對於小型項目,誰在乎?你有一個四核Pro,一個完整的構建需要幾分鐘,對吧?但是你仍然需要擔心第二個問題:循環依賴。 A.h
參考類別B
和B.h
參考類別A
。這實際上可能經常發生,並且可能非常無辜地進入系統。集合對象可能會引用其包含的對象的類型,並且對象可能會引用集合對象的類型。它只需要一個引用,因爲某些方法需要或返回該類型。如果您有標題導入其他標題,則發生這種情況的可能性會迅速接近統一。你用遞歸導入結束了,編譯時錯誤可能令人興奮。 「我知道,typdef被定義了!它就在那裏!它是進口的!「但是,當你導入這個頭文件時,它還沒有被解析,這是什麼導致你的錯誤如上所述
因爲這個原因,即使你不關心構建時間你應該),避免導入標題變爲頭......除了....
有些頭你有進口。你當然父。文件定義@protocol
你實現或typedef
使用。所以,是的,你必須包括這些。
那麼系統頭怎麼樣?那麼,他們永遠不會去c因爲他們不會引起遞歸進口,所以他們沒事。我不鼓勵人們在系統頭文件中使用@class
轉發聲明。它爲您的標題的用戶創造了額外的工作,沒有任何價值。要獲得良好的標題衛生,請記住將系統標題放在<尖括號>中,並將標題放在「引號」中。
所以這不是一個小問題,但簡單的規則是:避免在編譯器允許的任何時候將用戶頭文件導入到其他用戶頭文件中。
'typedef's和'protocols'怎麼樣? – Joost
你不會碰巧知道一個教程,或者使用它的代碼示例? – gargantuan