Nastal čas na kakao - Kopírování objektů - MujMAC.cz - Apple, Mac OS X, Apple iPod

3. června 2004, 00.00 | Na náš minulý rozbor toho, jak objekty vznikají a zanikají, je vhodné navázat popisem koncepce měnitelných a neměnných objektů. To proto, že kromě dosud popsaných postupů objekty mohou také vznikat jako kopie objektů dříve existujících – a způsob, jak jsou tyto kopie vytvářeny, je s koncepcí měnitelných a neměnných objektů úzce svázán.

Na náš minulý rozbor toho, jak objekty vznikají a zanikají, je vhodné navázat popisem koncepce měnitelných a neměnných objektů. To proto, že kromě dosud popsaných postupů objekty mohou také vznikat jako kopie objektů dříve existujících – a způsob, jak jsou tyto kopie vytvářeny, je s koncepcí měnitelných a neměnných objektů úzce svázán.

Vlastní kopírování

Ne všechny objekty prostředí Cocoa kopírování podporují: pro některé objekty by to totiž nemělo rozumný smysl – třeba taková instance třídy NSApplication, jež je v každé aplikaci jen jediná a zprostředkuje komunikaci kódu aplikace s operačním systémem: jaký by mělo smysl vytvářet její kopii?

Objective C proto pro kopírování využívá nám již známých protokolů: existuje protokol NSCopying, jemuž odpovídají právě ty třídy, jejichž instance lze kopírovat. Kromě toho existuje protokol NSMutableCopying, jemuž odpovídají právě ty třídy, od jejichž instancí lze vytvářet měnitelné kopie.

Kopii instance vytvoříme obecně tak, že jí pošleme zprávu copy:

NSString *novyString=[existujiciString copy];

Zpráva copy ovšem spolu s kombinací alloc/init patří mezi těch několik málo výjimek, jež sice vytvoří nový objekt, avšak nezařadí jej do správy paměti, takže garbage collector jej automaticky neuvolní.

To je proto, že v praxi zprávu copy daleko nejčastěji užíváme na místě zprávy retain v případech, kdy si chceme uchovat vlastní kopii daného objektu, nadále nezávislou na originálu:

@interface Foo:NSObject {
  NSString *title;
  ...
}
@end
@implementation Foo
...
-(void)setTitle:(NSString*)newTitle {
  [title autorelease];
  title=[newTitle copy];
}
...

Pokud bychom zde použili – podobně jako v příkladu v minulém dílu – "title=[newTitle retain];", vystavovali bychom se nebezpečí, že po chvíli obsah předaného objektu někdo nějak změní; změnil by se tak tedy i náš titulek (neboť s využitím zprávy retain sdílíme týž objekt, který nám odesilatel zprávy předal v parametru newTitle). To patrně nechceme!

(V minulém dílu toto risiko nehrozilo prostě proto, že textový objekt jsme tam nedostali od někoho jiného, ale sami jsme si jej vytvořili. Nebyl tedy sdílený, takže nám jej nikdo jiný změnit nemohl.)

V ostatních případech – pokud vytváříme kopii, již nechceme držet po delší dobu, než po dobu trvání dané metody – ovšem musíme explicitně použít zprávu autorelease:

...
NSArray *a=[[jinePole copy] autorelease];
// nějaké použití 'a'
// dále již 'a' potřebovat nebudu
...

Analogicky jako zpráva copy funguje i zpráva mutableCopy; ta však vždy vytvoří kopii, jejíž obsah můžeme měnit:

...
NSMutableArray *ma=[[pole mutableCopy] autorelease];
[ma addObject:jinyObjekt]; // nemění 'pole', jen mou kopii
...

Měnitelné a neměnné objekty

Základní myšlenkou koncepce měnitelných a neměnných objektů je dosažení vyšší efektivity (nejen, ale především) při kopírování objektů, aniž by se o to programátor musel vědomě starat.

Uvědomme si, že případů, kdy je zapotřebí vytvářet kopie objektů, je mnoho: služby "undo" v grafickém uživatelském rozhraní obvykle využívají kopií; naprosto klasickým případem je jeden z nejužívanějších objektů vůbec – hashovaná tabulka. Ukažme si právě tento případ: hashovaná tabulka v Cocoa samozřejmě je k dispozici, odpovídající třída se jmenuje NSDictionary. Základní dvě zprávy, jež nabízí, jsou

-(void)setObject:anObject forKey:aKey;
-objectForKey:aKey;

První z nich uloží do tabulky dvojici <klíč, hodnota>, druhá vyhledá hodnotu k zadanému klíči (v čase nezávisejícím na počtu hodnot v tabulce). Je zřejmé, že má-li hashovaná tabulka být konsistentní, musí interně udržovat ne sdílené odkazy na klíče, ale jejich neměnné kopie — kdyby v tabulce byly jen odkazy na klíče, mohl by se objekt reprezentující klíč kdykoli změnit, aniž by se o tom tabulka vůbec dozvěděla; hashovaná tabulka by se v takovém případě stala samozřejmě nekorektní. Implementace metody setObject:forKey: tedy musí vypadat přibližně takto:

-(void)setObject:anObject forKey:aKey {
  id myKey=[aKey copy]; // potřebuji vlastní neměnnou kopii
  id myVal=[anObject retain]; // hodnota se může klidně měnit (ale nesmí zaniknout)
  zaradit_do_tabulky(myKey,myVal); // hashováním se zde zabývat nepotřebujeme
}

Za těchto podmínek bude hashovaná tabulka pracovat korektně, ovšem zaplatíme za to zpomalením programu a větší spotřebou paměti: každý klíč vkládaný do tabulky se musí nejprve zkopírovat — to znamená, že potřebujeme dvakrát tolik paměti a navíc se program musí zdržovat kopírováním dat objektu. Přitom to v řadě případů není doopravdy zapotřebí: velmi často (v praxi téměř vždy, protože klíče obvykle bývají textové konstanty, tedy statické, neměnné objekty třídy NSString) se obsah klíčů stejně nikdy nebude měnit; hashovaná tabulka by si tedy ve skutečnosti vlastně mohla udržovat pouze odkazy na klíče — musela by ale 'vědět', které klíče se ještě mohou měnit a které ne.

Objektové prostředí se svým polymorfismem ovšem nabízí samozřejmé a velmi elegantní řešení: hashovaná tabulka samozřejmě nemůže vědět které objekty se budou měnit; mohou to ale vědět tyto objekty samy! Stačí zavést pro každý typ objektů pro který to dává rozumný smysl dvě třídy: třídu neměnných objektů a třídu objektů. které se mohou měnit — např. NSString (neměnné) a NSMutableString (měnitelné). Neměnné objekty pak nemusí nikdy vytvářet kopie; jejich metoda copy může být implementována nějak takto:

@implementation NSString // princip
...
-copy {
  return [self retain];
}
...
@end

Nyní funguje vše automaticky s nejvyšší možnou efektivitou: vkládáme-li do hashované tabulky klíč, který se nikdy nebude měnit, hashovaná tabulka bude udržovat pouze odkaz — žádná paměť navíc, žádná ztráta času, nic se nekopíruje. Pouze v případě že jako klíč využijeme měnitelný objekt — např. NSMutableString — kopie se vytvoří; v takovém případě se tomu ale stejně nemůžeme vyhnout. Navíc tentýž trik automaticky funguje nejen v hashované tabulce, ale kdekoli, kde potřebujeme okamžité kopie objektů: připravujeme např. program, který si pro funkci 'undo' musí zapamatovat momentální stav svých datových objektů? Nic jednoduššího — prostě vytvoříme kopie všech objektů reprezentujících data tak, že jim pošleme zprávu copy. Díky koncepci měnitelných a neměnných objektů nemusíme zkoumat, která data se mohou měnit, a která ne — fakticky se zkopírují jen ta, kterých se změny mohou týkat.

Cocoa proto v řadě případů nabízí dvojice tříd NSXXX a NSMutableXXX, kde objekty třídy NSXXX se nemohou měnit, zatímco objekty třídy NSMutableXXX ano (je tomu tak mimochodem i u třídy NSDictionary — metoda setObject:forKey: je tedy samozřejmě k dispozici pouze u objektů třídy NSMutableDictionary). Třída NSMutableXXX je vždy dědicem třídy NSXXX; měnitelné objekty tedy 'umějí' všechno, co neměnné, a navíc jsou schopny změn. Pošleme-li kterémukoli objektu třídy NSXXX zprávu copy, nevytvoří se žádná kopie; namísto toho získáme další sdílený odkaz na tentýž (neměnný) objekt. Pošleme-li však zprávu copy objektu třídy NSMutableXXX, dostaneme nový objekt třídy NSXXX, který bude obsahovat neměnnou kopii momentálního stavu původního objektu.

Složené objekty

Uvědomme si, že koncepce měnitelných a neměnných objektů zaručuje co nejefektivnější zkopírování i u složených objektů. Jako příklad vezměme objekt třídy NSMutableArray, který reprezentuje pole libovolných dalších objektů, do nějž můžeme přidávat nebo z něj odebírat (odpovídající neměnná třída NSArray reprezentuje pole, jehož obsah je při vytvoření pevně dán a nadále jej již nemůžeme měnit).

Obrázek ukazuje příklad objektu třídy NSMutableArray, obsahujícího (odkazy na) jak měnitelné, tak neměnné objekty. Vyžádáme-li si nyní zprávou copy neměnnou kopii momentálního stavu tohoto objektu, musí se vytvořit nový objekt třídy NSArray (protože existující objekt mutableArray je měnitelný) se stejným (a neměnným) obsahem. Nový objekt tedy může se starým sdílet odkazy na neměnné vnořené objekty, ale musí obsahovat vlastní (neměnné) kopie objektů, které byly měnitelné. Výsledek bude vypadat takto:

Čas od času bychom mohli potřebovat 'přece jenom' změnit neměnný objekt. Doslova to samozřejmě není možné — tím bychom celou koncepci měnitelných a neměnných objektů postavili na hlavu; můžeme si však pomocí zprávy mutableCopy vyžádat vytvoření vlastní měnitelné kopie objektu. Obsahuje-li původní objekt vnořené objekty, bude jeho měnitelná kopie obsahovat (odkazy na) tytéž objekty, a to i v případě, že tyto objekty samy jsou neměnné (chceme-li např. vytvořit měnitelnou kopii pole, je to proto, abychom do něj mohli přidávat nebo z něj odebírat další objekty; ne proto, abychom mohli měnit objekty v něm obsažené):

Koncepce měnitelných a neměnných objektů je velmi silným a šikovným mechanismem, který kromě výrazného zvýšení efektivity programů dokáže i omezit programátorské chyby: používáme-li neměnný objekt, nemůže se nám omylem stát, že jej některý úsek programu změní (z podobného důvodu byl např. v ANSI C zaveden modifikátor const). Rozdělení měnitelných a neměnných objektů na samostatné třídy NSXXX a NSMutableXXX navíc umožňuje některé takové chyby odchytit již při překladu — pokusíme-li se např. staticky typovanému objektu třídy NSArray poslat zprávu addObject: překladač vydá varování.