利用繼承，多態是一個很好的保持“對擴展開放，對更改封閉”（OCP）的辦法，也是最常見的一種方法。OC中還有另外兩種語法來支持OCP：protocol和category。Protocol只能定義一套接口，而不能提供實現。Category可以爲類提供額外的接口和實現。
那麼三者到底在使用上有什麼本質的區別呢？在我看來，protocol的作用是爲一些列類僅僅提供一套公用的接口，而完全沒有辦法也沒有可能去提供具體的一些實現；category則是爲一個已有的類提供一些額外的接口和實現；繼承則基於兩則之間，既可以像protocol一樣提供純粹的接口，也可以像category一樣提供完整的實現，而且繼承還能對類以後的功能進行改寫，所以說繼承的力量是最強大的。那麼具體在使用的時候各自都適合什麼樣的情況呢？
Protocol：定義行爲而不管誰去怎麼實現；就像外包項目中客戶一樣，他只是知道他需要什麼東西、功能，具體實現他不會。Delegate、datasource用protocol比較好。
Category: 是對一個功能完備的類一種補充。就像一個東西的主要基本功能都完成了，但可以用category爲這個類添加不同的組件、方法，使得這個類能夠適應不同情況的需求。比如：你已經有了一輛汽車，我們可以用category爲你的汽車添加各種之前沒有的功能，最後這輛汽車變成了超級跑車。（當某個類非常大的時候，category可以按不同的功能將類的實現分在不同的模塊中實現）
繼承：以上兩種，繼承都可以完成，但是可能會有很大的代價問題。一是通過繼承來進行擴展是一種耦合很高的行爲，對父類可以說是完全依賴；二是繼承由於對父類依賴，所以開發代價相對大，要求對父類的工作流程相對熟悉；三是繼承體系如果太複雜會導致整個系統混亂，難以維護。所以在能夠用上面兩種方法完成擴展的時候，就最好不要使用繼承。什麼情況纔是迫不得已要使用繼承呢？如果你既想提供一系列接口的定義，同時又想提供一些但是又不能提供全部的實現的時候，這種情況就要使用繼承了。所以這麼看來繼承是對上面兩種功能的一個黏合劑。
關於category的另外一些見解：
1，雖然category可以訪問類的實例變量，去不能創建新的實例變量，如果要創新的實例變量，請使用繼承；
2，在category中，不提倡對原有方法進行重載。原因非常簡單，在category中進行重載，無法對原方法進行訪問，而繼承中可以使用super。如果真的需要對原方法進行重載，請考慮繼承，比如我要定義一個繼承自UIViewController的類，就不能用Category，因爲，這我定義的這個類中，我要實現UIViewController中的viewDidLoad、init等方法，用了category後父UIViewController中的這些方法將無法被調用；
3，一個類可以定義多個category，但是如果不同category中存在相同方法，編譯器將按編譯順序來判斷，哪個分類在最後編譯就會覆蓋掉，有同樣方法的父類和比這個分類先編譯的分類裏的同名方法，所以說是使用最後編譯那個，因爲其覆蓋了父類和先編譯的分類中的同名方法；
4，在定義category時，我們可以僅僅給出方法定義，而不需要給出具體的實現。這在程序增量開發時是非常有幫助的；
5，category是可以被繼承的。在某個父類中定義了category，那麼他所有的子類都具有該category；
6，在需要爲某個類創建私有成員方法時，也用category的方式來實現。
Category不能完全代替子類，有以下幾個最大的缺點：
1），當在Category中覆蓋一個繼承的方法，在Category中的方法可以通過向super類發送一個消息來調用被繼承的方法。但是，如果Category中覆蓋的那個方法已經在這個類的其它Category定義過了，則之前定義的方法將沒有機會被程序調用
2），在Category中無法確定其能夠可靠的覆蓋某個方法，而這個方法已經在其它的Category中定義過。這個問題在使用Cocoa框架時尤其突出。當你想覆蓋某個框架已經定義好的方法時，該方法已經在其它Category中實現，這樣就無法確定哪個定義和實現會被最先使用，帶來很大的不確定性。
3），如果你重新覆蓋定義了一些方法，往往會導致這個方法在整個框架中實現發生了變化。舉例來說，如果你增加了NSObject中 windowWillClose:的實現，這會導致所有的窗口調用那個新實現的方法，從而改變所有NSWindows實例的行爲。這會帶來很多不確定性，並很有可能導致程序的崩潰。