Cocoa 編碼指南 框架開發者使用技巧和技術
Cocoa 編碼指南 框架開發者使用技巧和技術是本文要介紹的內容，相對于其他的開發者而言，框架開發者要更加注意編寫代碼的方式。因為許多客戶應用程序可能鏈接到框架，而這樣寬泛地暴露接口，就導致框架的任何缺點都可能通過系統放大。下面的條款討論一些框架編程技術，框架開發者可以利用它們來確保框架的高效性和完整性。
請注意：此處所討論的一些技術并不局限于框架開發。將之用于應用程序開發同樣卓有成效。
初始化
下述意見和建議涵蓋框架初始化方面的內容。
類的初始化
initialize類方法中的代碼只執行一次，它是類里面***個被調用的方法。我們通常利用該方法來設置類的版本號（請參考“版本化和兼容性”一節）。
對于繼承鏈中的每一個類，不論其是否實現initialize方法，運行時都會向它發送initialize消息。這可能導致一個類的initialize方法被多次調用（舉個例子,如果子類沒有實現initialize方法,則其父類的方法將被調用兩次）。但通常您希望始化代碼僅執行一次，為確保如此，您可以執行如下檢查：
- if (self == [NSFoo class]) {
- // the initializing code
- }
您不應該顯式地調用initialize方法。如果需要觸發初始化行為，則請調用一些無害的方法，例如：
- [NSImage self];
指定初始化函數
指定初始化函數是類的一個init方法，它調用超類的某個init方法（其他的初始化函數調用類自己定義的init方法）。每個公共類都應包含一個或多個指定初始化函數。舉些例子，NSView的initWithFrame:方法以及NSResponder的init方法都是指定初始化函數。在某些情況下，類的init方法并不想被重載，比如NSString和其他面向類簇的抽象類，因而其子類應該實現自己的初始化方法。
您應該明確標示出指定初始化函數，因為該信息對于想根據您的類來派生子類的開發者有重要的意義。一個子類可以只重載指定初始化函數，這對其他所有初始化函數沒有影響，它們仍將按其原先設計的行為工作。
在實現一個框架類時，您經常需要為其實現諸如initWithCoder:以及encodeWithCoder:這樣的歸檔方法。請注意，對象解檔時未發生的事情不要放在初始化代碼路徑里執行。對于實現歸檔功能的類，我們有一個比較好的方法可以做到這一點，那就是在類的指定初始化方法以及initWithCoder: 方法（該方法也是個指定初始化函數）中調用一個公共的例程。
初始化過程中的錯誤檢測
為確保能夠恰當地檢測并傳播錯誤，一個設計良好的初始化方法應完成如下步驟：
調用super的init方法對self重新賦值。
檢測指定初始化方法的返回值是否為nil。返回值為nil表明超類的初始化過程出現錯誤。
如果當前類在初始化的過程中出現錯誤，則請釋放對象并且返回nil值。
列表1 描述的方法可以完成上述步驟。
列表1 初始化過程中的錯誤檢測
- (id)init {
- if ((self = [super init]) != nil) { // call a designated initializer here
- // initialize object ...
- if (someError) {
- [self release]; // [self dealloc] or [super dealloc] might be
- self = nil; // better if object is malformed
- }
- }
- return self;
- }
版本化和兼容性
在向框架添加新類或新方法時，您通常沒必要為每個新功能群指定新的版本號。因為一般情況下，開發者會執行（或者說，應該執行）諸如respondsToSelector:這種Objective-C的運行時檢測來判斷給定的系統是否存在某種功能。開發者比較喜歡使用這種方式來檢測新功能，同時它也是最動態的方式。
不論如何，您可以使用數種技術以確保新版本的框架能被正確標志并盡可能地兼容早期版本。
框架的版本
如果已存在的新功能或者錯誤改正不容易通過運行時進行檢測，則您應該為開發者提供檢測這些變更的辦法。有一種辦法是把確切的框架版本號保存起來，然后讓該號碼對開發者可見：
把變更歸檔在一個版本號下面（例如，歸檔在發布記錄中）。
設置框架的當前版本號并且提供某種方法使之全局可見。您可以把版本號保存在框架的信息屬性列表（Info.plist），這樣就可以從該列表獲取版本號。
基于鍵的歸檔
如果框架對象需要被寫入到nib文件，則它們必須能夠自我歸擋 。另外，如果文檔使用歸擋機制來保存文檔數據，則您也要對它們做歸擋。在歸擋時，您可以使用“老風格”（利用initWithCoder:和encodeWithCoder:這樣的方法）。但是，為了更好地兼容過去、現在、以及未來的框架版本，您應該基于健進行歸檔。
基于鍵進行歸檔，對象就可以使用鍵來讀取或寫入被歸擋值。相對以往的歸擋機制，該方法可以在前向和后向兼容性上提供更多的靈活性。因為老歸檔機制要求代碼和讀取或寫入的值維持相同的順序，而且它也沒有什么好辦法來改變已寫到檔案的數據。如果您需要了解更多基于鍵的歸檔機制，請參考 Cocoa歸檔和序列化編程指南 （Archives and Serializations Programming Guide for Cocoa）一文。
對于正在編寫的新的類，請為其使用基于鍵的歸檔機制。如果之前已發布的類使用了老歸檔機制，您也無需再采取任何措施。如果對象實現了Mac OS X 10.2版本之前的歸檔機制，則它必須能從檔案中讀取內容并能其內容寫入到檔案。但如果您在Mac OS X v10.2及之后的平臺上為該對象添加新屬性，則您不必，實際上是不應該，將這些屬性保存到老檔案中（這樣做可能會使老檔案在更早的系統中變得不可讀取），這種情況下，新屬性應使用鍵值歸檔機制。
請注意下列和基于鍵歸檔相關的事實：
如果檔案中的某個鍵丟失，則在獲取這個鍵對應值的時候，依據所要求的類型，其返回值可能是nil、 NULL、NO、0、或者0。通過對該返回值進行測試，您可以減少寫到檔案中的數據。同時，還可以檢測某個鍵是否已被寫入到檔案中。
如果使用舊式歸檔，則initWithCoder:的實現需要獨自挑起兼容性的重擔。但如果使用鍵值歸檔，則歸檔方法和解檔方法都可以采取一些措施以保證兼容性。舉個例子，一個新版本的類的歸檔方法可能使用鍵來寫入一個新值，而依舊把早期的字段寫入到檔案中，這樣類的舊版本仍然可以理解該對象。與此同時，我們還可以在解檔方法中使用某種合理的方式以處理數值缺失的情況，從而為將來的版本保留一些靈活性。
在命名框架類的檔案鍵時，我們提倡使用和框架其他API元素一樣的前綴，前綴后面再使用實例變量名稱。您只要確保它的名稱不會和任意的子類或者超類名稱發生沖突即可。
如果您使用一個工具函數向檔案中寫入一個基本數據類型（換句話說，就是一個非對象的值），則請務必為該數值使用一個唯一鍵。舉個例子，如果您有一個對矩形歸檔的“archiveRect” 例程，則您應該為該函數傳入一個鍵作為參數。您可以直接把它作為檔案鍵；或者，如果這個例程向檔案寫入多個值（例如，寫入四個浮點數值），則它應該把每個數值自身獨有的位添加到所提供的鍵上面。
位字段對于編譯器和比特序有依賴關系，按照位字段現有的格式進行歸檔可能會有危險。只有當有多個位元需要被寫入檔案多次時，我們才會對位字段進行歸檔，這主要是為了提高性能。請參看 “位字段”一節 以獲取相關的建議。
對象的尺寸和保留字段
每個Objective-C的對象都有一個尺寸，它由對象自身實例變量加上對象所有超類具有的實例變量得到的總尺寸決定。如果改變了一個類的尺寸，則其擁有實例變量的子類必須重新編譯。為了保持二進制兼容性，通常情況下，我們不能通過向類添加新的實例變量或者去除類里面不必要的實例變量來改變對象的尺寸。
因此，對于新的類，為其留下幾個額外的”保留“字段以便于將來擴展是個不錯的想法。如果一個類只會有少數的幾個實例，這個想法顯然不成問題。但如果這個類會被實例化數千次，則您可能需要讓保留的單個變量的尺寸小一些（也就是說，任意對象都占用四個字節）。
對于較早的類的對象，如果它們的空間已經用完（并且假定實例變量沒有被導出成為公共變量），則您可以移動實例變量，或者把它們捆綁在一起,使之成為一個更小的字段。通過對實例變量進行重新排布，您就有可能添加新的數據而不會導致對象的總尺寸發生改變。或者您可以把一個剩余的保留槽作為指針，使它可以指向一塊額外的內存，然后您在對象初始化的時候分配這塊內存（并且在對象釋放的時候銷毀它）。又或者您可以把額外的數據放入到一張外部的哈希表（例如放入NSDictionary）；這種方法對于那些很少創建使用的實例變量具有很好的效果。
異常和錯誤
大多數Cocoa框架的方法不會強制要求開發者捕捉處理異常，因為程序正常執行時不會產生異常，而且我們通常也不使用異常來表示可預期的運行時錯誤或用戶錯誤。下面這些例子屬于可預期的運行時錯誤或者用戶錯誤：
文件找不到
用戶不存在
試圖打開應用程序中一個錯誤類型的文檔
把字符串轉化為特定編碼時出現錯誤
但是不管怎么樣， Cocoa確實會引發異常以指示下面這些編程錯誤或者邏輯錯誤：
數組索引越界
試圖改變一個不可改變的對象
錯誤參數類型
我們認為應用程序推向市場之前，開發者會對其進行測試，發現并解決這些類型的錯誤。因此，應用程序不需要在運行時處理上述異常。如果出現一個異常發生但應用程序沒有捕捉，則最頂層的缺省處理器通常會捕捉并且報告該異常，然后程序將繼續執行。開發者可以選擇替換掉這個缺省的異常處理器，新的處理器可以更詳細地描述什么地方發生了錯誤，并且還能夠讓用戶選擇是否保存數據并且推出應用程序。
錯誤是Cocoa框架不同于其他軟件庫的又一個地方。Cocoa的方法通常不返回錯誤碼。某些情況下，一個錯誤具有一個合理或者可能的原因，方法通過對一個布爾值或者對象返回值（nil/non-nil）進行簡單測試以判斷該情況；但是返回NO或者nil值的原因則被記錄在文檔中。另外，您不應該使用錯誤碼來指示需要在運行時處理的編程錯誤，相反您應該引發一個異常，或者在某些情況下，您也可以只記錄下該錯誤而不引發異常。
舉個例子，NSDictionary的objectForKey:方法會返回所找到的對象，如果對象找不到，則它會返回nil值。NSArray的objectAtIndex:法不可能返回nil值（除非我們把通用的編程語言約定重載成向nil對象發送消息都會返回nil值），因為NSArray對象不能保存nil值，并且所有的越界訪問都被定義成編程錯誤，這種錯誤引發異常而并不返回nil對象。如果對象不能使用用戶提供的參數進行初始化，許多init方法都會返回nil值
在少數情況下，一個方法需要多個不同的錯誤碼是合理的。這時，該方法需要將錯誤碼指定到一個傳引用參數，然后您可以利用該參數返回一個錯誤碼，也可以返回一個本地化的錯誤字符串，或者一些其他的可以描述錯誤的信息。舉個例子，您可以把錯誤轉換成NSError對象返回（請參看Foundation框架的NSError.h頭文件以獲取更多的細節）。而除了這個NSError對象，方法還能直接返回相對簡單的BOOL值或者nil值。另外要注意，這種方法的所有傳引用參數都是可選的。因此，如果發送者不想了解錯誤原因，它們可以傳一個NULL 值給錯誤碼參數。
重要： NSError類在Mac OS X v10.3之后的版本對外公開。
框架數據
框架數據的處理方式可能會對性能、跨平臺兼容性、以及其他某些方面產生影響。本節討論一些和框架數據相關的技術。
常量數據
出于性能的原因，您應盡可能多地把框架數據標志為常量，因為這樣可以減小Mach-O二進制文件的__DATA 段的尺寸。沒有const標記的全局或靜態的數據最終會存放在__DATA段的__DATA節。對于每一個使用該框架的應用程序實例，這種類型的數據都會占用內存。盡管多出500字節（舉個例子）好像沒那么糟糕，但是這有可能導致應用程序所需的內存頁面的數量增多—即每個應用程序都需要額外的四千字節的內存。
您應該為所有不變的數據添加const標記。具有const標記的數據塊，如果其中沒有char *類型的指針，則該數據會被存放在__TEXT段中（這會使數據成為真正的常量）；否則數據就會被存放在__DATA段中，但是這些數據不可以被寫入（除非預綁定未完成，如果預邦定已經完成，則只能在加載的時候，通過移動二進制文件的方式來寫入）。
您應該初始化靜態變量，這樣可以確保該變量被合并到__DATA段的__data節中而非__bss節。如果沒有明顯的值用于初始化靜態變量，則請使用0、NULL、0.0、或者任何恰當的值。
位字段
如果使用有符號的值來表示位字段，而代碼又假定這個位字段是布爾值，則可能會導致未定義的行為。只有一個位的位字段尤為如此。因為在這種情況下，這個位字段只能存儲0和 -1（取決于編譯器的實現），把它和1做比較，其結果總是不相等。因此，只有一個位的位字段應該是無符號的。舉個例子，如果您在代碼中遇到如下情況：
- BOOL isAttachment:1;
- int startTracking:1;
您應該把上述代碼中的類型改為unsigned int
和位字段相關的另一個問題是歸檔。通常情況下，您不應該按照當前格式將其寫入到磁盤或者檔案中，因為當我們在另外的架構或者編譯器中讀取這些字段時，它們的格式可能發生變化。
內存分配
在框架代碼中，如果可以的話，***是完全避免分配內存。如果出于某種原因，您需要一塊臨時的緩沖區，則通常情況下，使用棧比分配緩沖區更好。但是，棧的大小有限（棧總的大小通常為512千字節）， 因此是否使用棧取決于函數和您所需要的緩沖區的大小。通常情況下，如果您需要的緩沖區的大小不超過1000（或者是MAXPATHLE定義的值）字節，使用棧是合適的。
一個比較精細的方法是在開始的時候使用棧，但是如果所需要的內存的大小超過了棧緩沖區的大小，則切換到malloc內存分配方式。列表 2展示的代碼片段就是這么做的。
列表 2 使用棧內存和通過malloc分配的緩沖區
- #define STACKBUFSIZE (1000 / sizeof(YourElementType))
- YourElementType stackBuffer[STACKBUFSIZE];
- YourElementType *buf = stackBuffer;
- int capacity = STACKBUFSIZE; // In terms of YourElementType
- int numElements = 0; // In terms of YourElementType
- while (1) {
- if (numElements > capacity) { // Need more room
- int newCapacity = capacity * 2; // Or whatever your growth algorithm is
- if (buf == stackBuffer) { // Previously using stack; switch to allocated memory
- buf = malloc(newCapacity * sizeof(YourElementType));
- memmove(buf, stackBuffer, capacity * sizeof(YourElementType));
- } else { // Was already using malloc; simply realloc
- buf = realloc(buf, newCapacity * sizeof(YourElementType));
- }
- capacity = newCapacity;
- }
- // ... use buf; increment numElements ...
- }
- // ...
- if (buf != stackBuffer) free(buf);
語言問題
下面的條款討論和Objective-C語言相關的問題，包括協議、對象比較、以及向對象發送autorelease消息的時機。
向nil對象發送消息
在Objective-C中，只要消息的返回值是對象、任意的指針類型、或是其尺寸小于等于sizeof(void*)的整數型標量，我們就可以將其發送給nil對象，該消息將返回nil值。這個特性一種很有價值的編程資產，但是有一個問題需要注意。如果發送給nil對象的消息的返回值非上述類型（例如，消息返回任意的struct類型，或者浮點類型，或者任意的向量類型），則消息的返回值未定義。通常情況下，如果消息的返回值不是一個對象，則不要依賴這種行為，因為那是很糟糕的做法。在Power PC系統中，向nil對象發送上述類型的消息不會有問題，但對于其他架構來說，這種行為行不通。
對象比較
通用的對象比較方法isEqual:和與對象類型關聯在一起的比較方法（諸如isEqualToString:）有一個重要的不同。isEqual:方法允許任何對象作為參數，如果用于比較的對象屬于不同的類，則該方法將返回NO值。而諸如isEqualToString:以及isEqualToArray:這樣的方法通常都假定參數是某種特定的類型（和接收者一樣的類型）。因此，這種函數不會執行類型檢查，這使得它們運行速度比普通的對象比較方法快，但是安全性則不如之。對于那些從外部源獲取的值，例如從應用程序的的信息屬性表（Info.plist）或者應用程序的偏好設置獲取的值，在對其進行比較時，我們傾向于使用isEqual:方法，因為這種方法更安全；但如果我們已知道要進行比較的值的類型，則應使用isEqualToString:方法。
關于isEqual:方法，還有一點就是它和hash方法的聯系。存放在基于散列的Cocoa集合類里的對象（例如存放在NSDictionary或者NSSet中的對象）有一個基本的不變式，即如果[A isEqual:B] == YES，則[A hash] == [B hash]也成立。因此，如果您重寫了類的isEqual:方法，則您也應重寫hash方法以保持不變式成立。缺省情況下，isEqual:方法判斷對象地址指針是否相等，而hash方法則返回一個基于對象地址產生的hash數值，因此，這個不變式就可以保持成立。
協議
協議是Objective-C中一個有趣的概念，但是它們在Cocoa API中用得有限。之所以這樣做，有一個原因是協議有嚴格的設計要求。以某個含有十個方法的NSDataSource協議為例。如果某個開發人員遵循該協議并且實現其所有方法，而之后您又向該協議添加了一個新的方法，這就會破壞開發者和原有協議的一致性。因此，協議往往僅能包含它們***公開時所含有的方法集（除非您不期望其他開發者實現該協議）。因此，只有方法集不可能再增長時，才應使用協議。如果您必須擴展某個協議，則您應該添加一個新的協議，利用新協議來對原來的協議進行擴展，或者您可以把新方法添加在協議外部，并且在使用前檢查它是否存在。
基本上，上述的原因也可以解釋為何您不能使用常規協議來聲明委托方法。而把委托方法聲明為NSObjec上的范疇類— 即非正式的協議— 的另一個原因是我們可以選擇是否實現某個方法。
自動釋放的對象
返回對象值的方法或者函數，如果它們不是用于創建對象或者復制對象(new,alloc,copy 以及這些方法的變體)，則請務必讓其返回的對象可以autoreleased 。在此處，“自動釋放”并不一定表示對象應該顯式自動釋放-即在返回對象之前，向對象發送autorelease 消息。一般情況下，它僅表示返回值不是由調用者釋放。
出于性能方面的原因，請盡可能不要在方法實現中使用自動釋放的對象，特別是那些可能會在短時間內頻繁執行的代碼（例如在循環結構中，循環次數未知并且可能是很多的情況）使用。舉個例子，對于下面的情況，您不應該發送如下的消息：
- [NSString stringWithCharacters:]
而是應該發送下面的消息：
- [[NSString alloc] initWithCharacters:]
當您不再需要該字符串對象時，請顯示地釋放它。但是，請記住有些時候方法或者函數會返回自動釋放的對象，這時您需要向對象發送autorelease消息。
存取方法
在存取方法中作什么事情才是正確呢，這是個重要的問題。舉個例子，假設您在一個獲取方法中直接返回一個實例變量，而后立刻調用設置方法，則在釋放先前實例變量的時候就可能會有危險，因為它有可能把您之前返回的值給釋放掉。
Cocoa框架的原則是讓設置方法自動釋放實例變量先前的值,但某些情況下,所涉及的某個設置方法會被頻繁的調用（例如在一個很密集的循環中），這時候Cocoa的原則就不適用了。但在實踐中，這種情況非常罕見，除非是一些底層的對象才會如此。另外，諸如NSAttributedString、NSArray、以及NSDictionary這樣的通用集合不會自動釋放對象，這主要是為了維護對象的存在時間。它們只是簡單地留存或者釋放其含有的對象。另外，它們也應該對這一事實進行歸檔，這樣客戶程序就可以了解這些對象的行為。
對于現在正在編寫的框架代碼， 我們建議在get方法中使用自動釋放的對象，因為這是最安全的方法：
- (NSString *)title {
- return [[instanceVar retain] autorelease];
- }
- - (void)setTitle:(NSString *)newTitle {
- if (instanceVar != newTitle) {
- [instanceVar release];
- instanceVar = [newTitle copy];
- // or retain, depending on object & usage
- }
- }
另外，我們還需要考慮設置方法是使用copy方式還是使用retain方式。如果您所感興趣的是對象的值而非實際對象本身，則請使用copy方式。一個一般性的經驗法則是對實現NSCopying協議的對象使用copy方式（您不應該在運行時檢測對象是否實現NSCopying協議，而應該直接查找參考文檔）。通常情況下,諸如字符串、顏色、URL這樣的對象應該能被復制；而像視圖、窗口這樣的對象則應該可以被保持。而至于其他的對象（例如數組），是使用copy還是使用retain，則要根據具體情況決定。
小結：Cocoa 編碼指南 框架開發者使用技巧和技術的內容介紹完了，希望本文對你有所幫助！關于Cocoa 編碼指南的更多內容請參與編輯推薦。
