Objective-C優(yōu)點(diǎn)及缺點(diǎn)

時(shí)間：2022-02-08 13:30:01 | 來(lái)源：信息時(shí)代

時(shí)間：2022-02-08 13:30:01 來(lái)源：信息時(shí)代

Objective-C是非常'實(shí)際'的語(yǔ)言。它使用一個(gè)用C寫(xiě)成、很小的運(yùn)行庫(kù)，只會(huì)令應(yīng)用程序的大小增加很小，和大部分OO系統(tǒng)使用極大的VM執(zhí)行時(shí)間會(huì)取代了整個(gè)系統(tǒng)的運(yùn)作相反。ObjC寫(xiě)成的程序通常不會(huì)比其原始碼大很多。而其函式庫(kù)（通常沒(méi)附在軟件發(fā)行本）亦和Smalltalk系統(tǒng)要使用極大的內(nèi)存來(lái)開(kāi)啟一個(gè)窗口的情況相反

Objective-C的最初版本并不支持垃圾回收。在當(dāng)時(shí)這是爭(zhēng)論的焦點(diǎn)之一，很多人考慮到Smalltalk回收時(shí)有漫長(zhǎng)的'死亡時(shí)間'，令整個(gè)系統(tǒng)失去功用。Objective-C為避免此問(wèn)題才不擁有這個(gè)功能。雖然某些第三方版本已加入這個(gè)功能（尤是GNUstep）,Apple在其MacOSX10.3中仍未引入這個(gè)功能。不過(guò)令人欣慰的是在Apple發(fā)布的xCode4中已經(jīng)支持自動(dòng)釋放啦，我不敢冒昧地說(shuō)那是垃圾回收，因?yàn)閮烧邫C(jī)制不同，在xCode4中的自動(dòng)釋放，也就是ARC(AutomaticReferenceCounting)機(jī)制,是不需要用戶手動(dòng)去Release一個(gè)對(duì)象，而是在編譯期間，編譯器會(huì)自動(dòng)幫你添加那些以前你經(jīng)常寫(xiě)的。

另一個(gè)問(wèn)題是ObjC不包括命名空間機(jī)制(namespacemechanism)。取而代之的是程序設(shè)計(jì)師必須在其類別名稱加上前綴，時(shí)常引致沖突。在2004年，在Cocoa編程環(huán)境中，所有MacOSX類別和函式均有'NS'作為前綴，例如NSObject或NSButton來(lái)清楚分別它們屬于MacOSX核心；使用'NS'是由于這些類別的名稱在NeXTSTEP開(kāi)發(fā)時(shí)定下。

雖然Objective-C是C的母集，但它也不視C的基本型別為第一級(jí)的對(duì)象。

和C 不同，Objective-C不支援運(yùn)算子多載（它不支持ad-hoc多型）。亦與C 不同，但和Java相同，Objective-C只容許對(duì)象繼承一個(gè)類別（不設(shè)多重繼承）。Categories和protocols不但可以提供很多多重繼承的好處，而且沒(méi)有很多缺點(diǎn)，例如額外執(zhí)行時(shí)間過(guò)重和二進(jìn)制不兼容。

由于Obj-C使用動(dòng)態(tài)運(yùn)行時(shí)類型，而且所有的方法都是函數(shù)調(diào)用（有時(shí)甚至連系統(tǒng)調(diào)用（syscalls）也如此），很多常見(jiàn)的編譯時(shí)性能優(yōu)化方法都不能應(yīng)用于Obj-C（例如：內(nèi)聯(lián)函數(shù)、常數(shù)傳播、交互式優(yōu)化、純量取代與聚集等）。這使得Obj-C性能劣于類似的對(duì)象抽象語(yǔ)言（如C ）。不過(guò)Obj-C擁護(hù)者認(rèn)為既然Obj-C運(yùn)行時(shí)消耗較大，Obj-C本來(lái)就不應(yīng)應(yīng)用于C 或Java常見(jiàn)的底層抽象。