POP （protocol Oriented Programing POP） 面向協(xié)議編程
OOP （Object Oriented Programing） 面向?qū)ο缶幊?/p>
OOP的優(yōu)點
1）封裝和權(quán)限控制
OC：.h文件負(fù)責(zé)聲明公共變量和方法，.m 文件負(fù)責(zé)聲明私有變量， 并實現(xiàn)所有方法。
Swift：也有public、internal、fileprivate、private 等權(quán)限控制；
2）命名空間
Swift：不同的class即使命名相同， 在不同的bundle中， 由于命名空間不同，它們依然可以和諧共存，毫無沖突；在App體積很大的時候，bundle很多時候，這一點特別有用；
OC： 沒有命名空間， 所以很多類在命名的時候都加入了“駝峰式”的前綴；
3）擴展性：
Swift：可以通過extension 來增加新方法， 通過動態(tài)特性亦可以增加變量， —— 可以保證在不破壞原來代碼封裝的情況下實現(xiàn)新的方法。
OC：可以使用category實現(xiàn)類似功能;
在Swift和OC中， 還可以通過protocol 和代理模式實現(xiàn)更加靈活的擴展
4）繼承和多態(tài)
同其他語言一樣， 在iOS中，可將公共的方法和變量定義在父類中，在子類繼承時再各自實現(xiàn)對應(yīng)的功能，高效實現(xiàn)代碼復(fù)用，針對不同的子類，從而大大增加代碼的靈活性；
OOP 缺點
1）隱式共享
class 是引用類型， 當(dāng)在代碼中的某處改變某個實例變量時， 另一次在調(diào)用此變量時就會受此修改的影響；
很容易造成異常， 尤其是在多線程上， 我們經(jīng)常會遇到資源競選(Race condition) 就屬于這種情況。
解決多線程時枷鎖， 加鎖有可能會引起死鎖或者代碼復(fù)雜度劇增。 解決這個問題最好的方案是諸如struct這樣的值類型取代class
2）冗余的父類
eg： UIViewController 需要加入一個handleSomethiing() 方法， OOP的是在其extension直接添加這個方法，隨著新方法越來越多， 導(dǎo)致UIViewController越來越冗余， 隨著新方法越來越多， 導(dǎo)致職權(quán)不明確、依賴、冗雜等多種問題。
3）多繼承
swift 和OC都不支持多繼承， 因為他會造成“菱形”問題，
即為：多個父類實現(xiàn)了同一個方法，子類無法判斷繼承哪個父類的情況。 C++ 就會有這種情況， 使用了抽象類的實現(xiàn)方式確定繼承方法；
在Java中， 有interface的解決方案， 在Swfit有類似的protocol
為什么Swift 要推出全新的POP？
1）OOP自身的缺點， 在繼承和代碼復(fù)用等方面， 其靈活度不高， POP恰好可以解決這個問題；
2）POP可以保證Swfit作為 靜態(tài)語言的安全性， 而OC時代的OOP， 其動態(tài)特性經(jīng)常會導(dǎo)致異常
3）OOP無法應(yīng)用于值類型， 而POP可以將其優(yōu)勢擴展到結(jié)構(gòu)體（struct）和枚舉(enum)類型中；
OOP優(yōu)點
1）更加靈活：上面的handleSomething方法， 通過服從協(xié)議的同時， 增加了代碼的可讀性；
2）減少依賴：相對于傳入具體的實例變量，可以傳入protocol來實現(xiàn)多態(tài)，同時，在測試也可以利用protocol 來模擬真實的實例，減少對對象以及其它實現(xiàn)的依賴
3）消除動態(tài)分發(fā)的風(fēng)險
POP面試題： 要給一個UIButton增加一個點擊后抖動的 效果，應(yīng)該怎么實現(xiàn)？
三種方案：
1）方案一：實現(xiàn)一個自定義的UIButton類， 在其中添加點擊抖動效果的方法【shake方法】；
2）方案二：寫一個UIButton的Extension， 然后在其中增加share方法
3）方案三：定義一個protocol，然后將協(xié)議擴展protocol extension中添加shake方法
分析：
1）性能擴展性不好， 復(fù)用性不好
2）可讀性很差， 因為不是每個人都知道有這個方法
3）解決了復(fù)用性、可讀性、維護(hù)性 這個三個難題。
本文由mdnice多平臺發(fā)布
