第3章 接口與API設計 52條筆記

第15條： 用前綴避免命名空間沖突

Objective-C 沒有其他語言那種內置的命名空間機制 。鑒于此，我們在起名時要設法避免潛在的命名沖突，否則很容易就重名了。如果發生命名沖突 naming clash ,那么應用程序的連接過程就胡出錯。

避免此問題的唯一做法就是變相實現命名空間：為所有名稱都加上適當的前綴。

?

第16條： 提供全能初始化方法

把這種可為對象提供必要信息以便其能完成工作的初始化方法就做 指定初始化方法 designated initialzier.

如果創建實例的方法不止一種，那么這個類就會有多個初始化方法。不過要在其中選定一個作為designated initializer ，令其他初始化方法都來調用它。

上面幾個初始化方法中，initWithTimeIntervalSinceReferenceDate:是 designated initializer.

?

第23條：通過委托與數據源協議進行對象間通信

該模式的主旨是 ： 定義一套接口，某對象若想接受另一個對象的委托，則需要遵從此接口，以便成為其委托對象 delegate.而這另一個對象則可以給其委托對象回傳一些信息，也可以在發生相關事件時通知委托對象。

?

一般通過協議 這項語言特性來是實現此模式，整個Cocoa系統框架都是這么做的。

第24條： 將類的實現代碼分散到便于管理的數個分類之中

類中經常容易填滿各種方法，而這些方法的代碼則全部堆在一個巨大的實現文件中。

通過Objective-C的分類機制，把類代碼按邏輯劃入幾個分區中，這對開發與調試都有好處。

?

把個人信息建模為類。

可以用分類機制把剛才的類改寫成下面這樣：

現在，類的實現代碼按照方法分成了好幾個部分。所以說，這項語言特性當然就叫做分類 啦 。

使用分類機制之后，依然可以把整個類都定義在一個接口文件中，并將其代碼寫在一個實現文件中?？墒请S著分類數量增加，當前這份實現文件很快就會膨脹。此時，可以把每個分類提取到各自的文件中去。

以EOCPerson為例，可以按照其分類分成以下幾個文件：

通過分類機制，可以把類代碼分成很多易于管理的小塊，以便單獨檢視 。使用分類機制之后，如果想用分類中的方法，那么要記得在引入EOCPerson.h時一并引入分類的頭文件。

雖然稍微有點麻煩，不過分類仍然是一種管理代碼的好方法。

第25條：總是為第三方的分類名稱加前綴。

第26條： 勿在分類中聲明屬性

屬性是封裝數據的方式。盡管從技術上說，分類也可以聲明屬性，但這種做法應該盡量避免。

關聯對象能夠解決在分類中不能合成實例變量的問題。

這樣做可行，但不太理想。要把相似的代碼寫很多遍，而且在內存管理問題上容易出錯，因為我們在為屬性實現存取方法時，經常會忘記遵從其內存管理語義。

盡管這個方法不壞，但筆者不推薦。

把屬性定義在主接口中要比定義在分類里清洗得多。

至于分類機制，則應將其理解為一種手段，目標在于擴展類的功能。

有時候只讀屬性還是可以在分類中使用的。

由于獲取方法并不訪問數據，而且屬性也不需要由實例變量來實現，所以可以像下面這樣來實現分類：

第27條： 使用class-continuation 分類 隱藏實現細節

第28條：通過協議提供匿名對象

協議定義了一系列方法，遵從此協議的對象應該實現他們。于是，我們可以用協議把自己所寫的API只中的實現細節隱藏起來，將返回的對象設計為遵從此協議的純id 類型。

在定義受委托者 delegate這個屬性時，可以這樣寫

@PRoperty (nonatomic ,weak )id <EOCDelegate>delegate;

由于該屬性的類型是id<EOCDelegate>，所以實際上任何類的對象都能充當這一屬性，即便該類不繼承自NSObject也可以，只有遵循EOCDelegat協議就行。