Nastal čas na kakao - Využití kategorií namísto dědičnosti - MujMAC.cz - Apple, Mac OS X, Apple iPod

22. července 2004, 00.00 | V minulém dílu jsme si začali povídat o tom, jaké alternativní techniky se v Cocoa často využívají namísto dědičnosti: ukázali jsme si, jak funguje delegace a zběžně jsme se seznámili s mechanismem akce/cíl, jemuž se budeme daleko podrobněji věnovat začas, v rámci služeb souvisejících s grafickým uživatelským rozhraním. Dnes si ukážeme další trik, který bývá často vhodnější, než "dědění": využití kategorií pro rozšíření služeb některé ze standardních tříd o požadované API.

V minulém dílu jsme si začali povídat o tom, jaké alternativní techniky se v Cocoa často využívají namísto dědičnosti: ukázali jsme si, jak funguje delegace a zběžně jsme se seznámili s mechanismem akce/cíl, jemuž se budeme daleko podrobněji věnovat začas, v rámci služeb souvisejících s grafickým uživatelským rozhraním. Dnes si ukážeme další trik, který bývá často vhodnější, než "dědění": využití kategorií pro rozšíření služeb některé ze standardních tříd o požadované API.

Minule jsme psali, že v řadě více či méně objektových prostředí je zvykem takřka na vše možné i nemožné využívat dědičnosti: ... co třeba potřebujeme-li prioritní frontu objektů? Inu, vytvoříme podtřídu standardní třídy Array, a přidáme patřičné služby. V hrubých rysech by to vypadalo nějak tak, jak ukazuje první obrázek:

V Cocoa se to tak obvykle nedělá; bylo by to moc práce a málo muziky. Pokud chceme jen sestavit specifické API, jež nepožaduje nijak zásadní rozšíření služeb, je nejjednodušší vzít již hotovou třídu – a služby doplnit prostřednictvím kategorie. To se "klasickému" vytváření podtřídy hodně podobá; z hlediska programátora je vlastně jediný rozdíl v tom, že není třeba vytvářet novou třídu; nové metody však implementuje přesně stejným způsobem, jako by tomu bylo při využití dědičnosti. To vidíme na druhé ilustraci:

Rozhraní

Ukažme si nejjednodušší příklad implementace zásobníku pomocí kategorie (prioritní fronta, o níž jsme se zmiňovali, by se implementovala podobně, ale bylo by potřeba více kódu; u zásobníku se můžeme lépe soustředit na využití kategorie, neboť vlastní kód je zcela triviální). Jednou ze standardních tříd, jež knihovny Cocoa nabízejí, je dynamické pole objektů, NSMutableArray. Je celkem zřejmé, že nejjednodušší bude implementovat zásobník právě doplněním služeb k této třídě – v rozhraní prostě jen deklarujeme nové zprávy:

@interface NSMutableArray (StackAccess)
+stack; // vytvoří a vrátí nový zásobník
-(void)push:object;
-pop; // pro prázdný zásobník vyvolá výjimku
@end

Povšimněme si "třídní" metody stack: v našem jednoduchém případě je skutečně zbytečná, stejně dobře bychom mohli vytvářet přímo objekty třídy NSMutableArray. V řadě případů však požadujeme při vytvoření objektu i nějakou speciální inicializaci, a pak je takováto služba zapotřebí; ukážeme si ji proto i v našem příkladu, jakkoli v jeho případě je triviální.

Implementace

Implementace je víceméně zřejmá – jen přímo převedeme zásobníková primitiva na primitiva dynamického pole:

@implementation NSMutableArray (StackAccess)
+stack {
  return [self array];
}
-(void)push:object {
  [self addObject:object];
}
-pop {
  id o=[[[self lastObject] retain] autorelease];
  [self removeLastObject];
  return o;
}
@end

Za zvláštní povšimnutí stojí dvě věci: předně, je vhodné si uvědomit, že proměnná self v metodě stack znamená třídu NSMutableArray (neboť jde o metodu třídy), ale v metodě push: označuje instanci.

Druhá věc, jež si zaslouží podrobnější výklad, je na první pohled "nesmyslná" kombinace zpráv retain a autorelease v metodě pop: podle toho, co víme o správě paměti, se přece tyto dvě zprávy navzájem v podstatě ruší; jaký tedy může mít taková kombinace smysl?

Inu, smysl má, a velmi dobrý: jde o to, že pokud do pole NSMutableArray vložíme nějaký objekt, pole jej "přidrží" zprávou retain; pokud však jej odstraníme, pole jej uvolní zprávou release (nikoli autorelease). Pokud bychom tedy dvojici zpráv retain/autorelease v metodě pop nepoužili, mohl by být objekt ve chvíli, kdy je na základě zprávy removeLastObject z pole odstraněn, skutečně zrušen, a příkaz return o by vrátil nesmysl (adresu již neexistujícího objektu). Tomu právě zabrání zpráva retain – a zpráva autorelease se postará o to, že objekt bude automaticky zrušen později (pokud si jej zprávou retain nikdo jiný "nepřidrží").

Jaké jsou výhody a nevýhody takovéhoto využití kategorie?

+ kategorie funguje stejně dobře s obyčejnou třídou i se sdruženými třídami (class clusters); jak víme z dílu, věnovaného skrytým podtřídám, s nimi by se obyčejná dědičnost nedala přímo využít;

+ objekty "typu zásobník" jsou oboustranně stoprocentně kompatibilní s instancemi NSMutableArray (samozřejmě, neboť v obou případech fakticky jde o objekty téže třídy). Není proto např. problém, aby nějaký modul vytvořil pole NSMutableArray, a jiný modul s týmž objektem pracoval jako se zásobníkem. To by nebylo jednoduše možné, kdyby šlo o objekty různých tříd (tam by pak platila kompatibilita pouze jedním směrem);

+ příjemným důsledkem minulého bodu je neomezené využití všech knihovních služeb: máme-li např. služby pro archivaci objektů do souborů ve formátu XML, jež podporují pole, můžeme je ihned a bez jakékoli změny využít i pro náš zásobník. Pokud bychom pro zásobník měli samostatnou třídu, bylo by nutné použitý formát XML rozšířit tak, aby tuto třídu explicitně podporoval. Podobně je tomu např. při sdílení objektů mezi různými procesy a podobně;

- obecnou nevýhodou kategorie je, že není možné přímo přidávat instanční proměnné. Pokud bychom to potřebovali, existují sice triky jak to zaonačit, avšak obvykle už je lepší využít spíše vkládání objektů (nebo "klasické" dědičnosti, pokud nenarazíme na sdružené třídy či jiný problém);

- při využití kategorie tímto způsobem také nelze změnit standardní chování základní třídy (to samozřejmě musí zůstat plně k dispozici pro všechny moduly, jež třídu využívají běžným způsobem). Pokud tedy požadované chování "nového objektu" není jen rozšířením služeb "původního", ale má se v něčem lišit, kategorii použít nelze.

Tam, kde je některá z těchto nevýhod kritická, máme k dispozici vkládání objektů; to si ukážeme příště.