Nastal čas na kakao - Jak správně psát v Objective C - MujMAC.cz - Apple, Mac OS X, Apple iPod

23. června 2004, 00.00 | V následujících několika dílech našeho seriálu se budeme věnovat tomu, jak v Objective C správně programovat: seznámíme se s řadou standardních konvencí a vzorců, jichž je vhodné používat: nejenže nám usnadní život, ale navíc zajišťují chování, jež ostatní programátoři od našich tříd a metod automaticky očekávají.

V následujících několika dílech našeho seriálu se budeme věnovat tomu, jak v Objective C správně programovat: seznámíme se s řadou standardních konvencí a vzorců, jichž je vhodné používat: nejenže nám usnadní život, ale navíc zajišťují chování, jež ostatní programátoři od našich tříd a metod automaticky očekávají.

Samozřejmě, že žádné z pravidel, o nichž se zmíníme, není striktním předpisem, jenž by bylo nutné dodržet vždy a bez výjimky. Obecně však platí, že pokud chceme některé z těchto pravidel porušit, měli bychom k tomu mít dobrý důvod – a také bychom měli jak tento důvod, tak i konkrétní způsob porušení konvencí velmi dobře zdokumentovat.

Začneme tím nejjednodušším: konvencemi pro názvy identifikátorů a podobně. V dalších dílech se podíváme na zajímavější triky a postupy, jako třeba jak správně psát inicializátory (při té příležitosti si také vysvětlíme, proč musí být dvojice zpráv alloc/init vždy spojena do jediného příkazu), jak zajistit uvolnění zdrojů při rušení objektu, popíšeme si správnou implementaci tzv. accesorů – metod, zajišťujících přístup k vnitřním proměnným objektu –, naučíme se správně používat direktivy #import a @class...

Copak je po jméně?

Je sice pravda, že co identifikátorem zvou, i zváno jinak fungovalo by stejně; dost zásadní rozdíl však nastane ve chvíli, kdy jeden programátor má číst kód druhého – nebo třeba i svůj vlastní po několika letech. Mnohaleté zkušenosti programátorů v Cocoa (a v jeho předchůdcích, OpenStepu i API NeXTStepu) vedly k následujícím pravidlům. Jakkoli některá z nich jsou jistě jen věcí vkusu, jiná jsou důležitá i pro funkci programu – kupříkladu dodržení alespoň základních konvencí při psaní accesorů je nutná pro správnou funkci služby key/value coding (my se jí budeme věnovat až později, neboť jde o poměrně pokročilou službu pro zkušenější programátory – začátečníci ji obvykle využívají jen nepřímo a nepotřebují jí rozumět do hloubky).

Základy

Nejzákladnější pravidla jsou poměrně jednoduchá:

• jména proměnných a zpráv (a tedy i metod) a lokálních funkcí (označených static) by měla začínat malým písmenem;
• jména globálních objektů – tříd, protokolů, kategorií, konstant, globálních funkcí, a také zdrojových souborů – by měla začínat velkým písmenem (a prefixem, tomu však věnujeme samostatný odstavec za chvilku);
• jména složená z více slov by měla používat pro oddělení velké písmeno na začátku dalšího slova (tedyAsiNějakTakto), a ne podtržítko či jiný oddělovač;
• speciálně, podtržítko jako prefix je reservováno firmou Apple; neměli bychom proto deklarovat vlastní proměnné nebo metody, jež podtržítkem začínají;
• pro konsistenci s programovacím jazykem a srozumitelnost ostatním programátorům by jména (i komentáře) měly obecně být v angličtině (v našem seriálu toto pravidlo často porušujeme pro lepší čitelnost českého výkladu – ve skutečném kódu je to samozřejmě něco jiného).

Navíc bychom neměli příliš užívat zkratek. Jména zpráv by měla předesílat typ argumentu, pokud to dává smysl: appendFormat:, appendObject:, appendString:. Naopak je většinou zbytečné ve jménech uvádět typ objektu, k němuž se vztahují: StringClass nebo NumberObject by se (ve většině případů) měly spíše jmenovat String nebo Number. Výjimkou jsou konstanty některých specifických typů: pro celočíselné konstanty, jež obsahují bitové masky, se obvykle užívá přípona ...Mask; podobně pro textové konstanty, jež jsou jmény výjimek, se obvykle užívá přípona ...Exception, a pro jména notifikací (speciálních zpráv, jež může systém rozesílat řadě objektů i mezi různými procesy) se užívá přípona ...Notification. Jména notifikací by také obecně měla obsahovat část ...Did... nebo ...Will..., jež určuje zda akce, na niž notifikace upozorňuje, již nastala, nebo teprve má nastat (např. NSWindowDidCloseNotification, nebo NSApplicationWillTerminateNotification).

Samozřejmě, u privátních objektů to není tak důležité. Kdykoli ale navrhujeme veřejné rozhraní tříd a/nebo protokolů, vyplatí se nejprve se podívat do hlavičkových souborů Cocoa na obdobné objekty, a zvolit jména podobného typu, jaká tam nalezneme.

Zvláště důležité to je u zpráv, jež lze využívat polymorfně: vytváříme-li např. třídu, jejíž instance mohou za vhodných podmínek vyjadřovat číslo, měli bychom pro přístup k této číselné hodnotě rozhodně implementovat metodu jménem intValue a žádnou jinou – to pak totiž umožní polymorfní využití objektů této třídy spolu s instancemi tříd NSNumber, NSString a dalších.

Zprávy a metody

Jména zpráv a metod je vhodné také navrhovat podle několika základních pravidel; usnadní to ostatním programátorům – a nakonec i nám – práci s třídou, neboť budou-li jména metod odpovídat těmto konvencím, lépe a snáze si je zapamatujeme:

• zprávy, jež vracejí atributy, by se měly jmenovat prostě podle daného atributu: size, height, name, ... Žádná pomocná slovesa, speciálně žádná předpona "get", na niž jsou zvyklí programátoři v Javě!
• pokud je atribut boolovského typu, může být na místě předpona is... nebo has...;
• použití předpony get... je na místě pouze u zpráv, jež vracejí výsledky referencí (takové zprávy se obvykle užívají pro získání více hodnot najednou).

Pro accesory platí ještě více pravidel; na ta se ale podrobněji podíváme později, až se budeme zabývat accesory samotnými.

Prefixy

Vzhledem k tomu, že Objective C nemá namespaces, je zapotřebí u všech globálních objektů (tříd, protokolů, kategorií, konstant, globálních funkcí) důsledně užívat prefixů. Firma Apple užívá základní prefix NS (který pochází ještě z dob, kdy firma Sun mívala schopné objektové programátory, již spolupracovali s firmou NeXT na návrhu rozhraní OpenStep – jde o zkratku NeXT/Sun), a několik dalších (AB, IB pro AddressBook a InterfaceBuilder). U jednoduchých tříd, jež jsou součástí testovacích "in-house" prográmků – tak tomu je i ve většině příkladů v našem seriálu – si samozřejmě můžeme prefix odpustit zcela; v produkčním kódu bychom však prefixy měli používat důsledně.

Trochu citlivé téma je délka prefixu: je zřejmé, že čím delší prefix, tím je menší pravděpodobnost, že se náhodou "strefí" do prefixu cizího a dojde tak k problémům; na druhou stranu, příliš dlouhé prefixy jsou nepohodlné. Zde si každý musí vybrat sám; já např. pro většinu globálních objektů používám prefix "OC", ale u objektů, u nichž je vysoká pravděpodobnost použití v cizím kódu (např. u veřejných frameworků) užívám raději delšího prefixu "OCS".

Je třeba si dát pozor i na to, že v určitém smyslu jsou globální i jména metod, jež prostřednictvím kategorií přidáváme ke standardním třídám Cocoa. Proto je vhodné prefixy používat i v těchto případech – aby nemohlo dojít k problémům kdyby jiná kategorie jiného programátora přidala k téže třídě jinou metodu téhož jména (runtime systém Objective C by v takovém případě vybral "náhodně" jednu z metod v závislosti na tom, v jakém pořadí jsou kategorie zavedeny do paměti):

@interface NSString (OCSNSStringAdditions)
-(NSDecimalNumber*)ocsDecimalNumberValue;
@end

Výjimkou z tohoto pravidla samozřejmě jsou úmyslně přidávané polymorfní metody (intValue apod.).