Nastal čas na kakao - Accesory: přístup k proměnným instancí - MujMAC.cz - Apple, Mac OS X, Apple iPod

31. srpna 2004, 00.00 | Už v minulém dílu jsme narazili na to, že je z řady důvodů šikovné snažit se nepracovat s instančními proměnnými přímo: lepší je "zabalit" je do samostatného API, několika málo jednoduchých metod, jejichž prostřednictvím – a jenom jejich prostřednictvím – se s proměnnými zachází. Všechen ostatní kód pak využívá právě těchto metod; obvykle těmto metodám říkáme accesory.

Už v minulém dílu jsme narazili na to, že je z řady důvodů šikovné snažit se nepracovat s instančními proměnnými přímo: lepší je "zabalit" je do samostatného API, několika málo jednoduchých metod, jejichž prostřednictvím – a jenom jejich prostřednictvím – se s proměnnými zachází. Všechen ostatní kód pak využívá právě těchto metod; obvykle těmto metodám říkáme accesory.

Připomeňme si alespoň nejzákladnější výhody tohoto přístupu:

• kód se snáze udržuje, neboť případné změny v instančních proměnných se promítnou jen do několika jasně definovaných metod – všechny ostatní pracují "skrz" accesory, takže není třeba je měnit;
• lze spolehlivě a bezpečně měnit implementaci třídy, ponecháme-li accesory beze změny: můžeme např. lineárně prohledávané pole pro větší efektivitu nahradit hashovanou tabulkou;
• speciálně, lze snadno a spolehlivě implementovat alokaci zdrojů na vyžádání, jak jsme si ji ukázali v minulém dílu: jestliže všechny ostatní metody přistupují k proměnné prostřednictvím accesoru, je zřejmé, že si bez jakéhokoli risika můžeme dovolit obsah proměnné vytvořit až když bude accesor poprvé vyvolán;
• accesory jsou samozřejmě nutné pro případy, kdy k instančním proměnným přistupují ostatní objekty (sice bychom se jim i zde mohli vyhnout využitím direktivy @public, ovšem to by byl extrémně špatný objektový návrh, jdoucí zcela proti pravidlu zapouzdření);
• na rozdíl od přímého přístupu accesory lze reimplementovat v rámci podtřídy a/nebo kategorie.

Má využívání accesorů také nějaké nevýhody? Inu, takřka žádné; jen v celkem výjimečných případech, kdy skutečně žádná z výše popsaných výhod nemá zhola žádnou váhu, můžeme přímým přístupem k proměnným ušetřit pár řádků kódu a – naprosto nevýznamně – urychlit aplikaci. Situaci zhruba ilustruje obrázek, v němž černé šipky representují přístup k instančním proměnným; vlevo je implementace bez accesorů, vpravo s jejich využitím:

Mimochodem – samozřejmě, že máme-li již accesory, jež mají "monopol" na přístup k nějaké instanční proměnné, pak obecně (nikoli bez výjimek) mezi metody, jež při rozumném objektovém návrhu nepřistupují k instančním proměnným přímo, nýbrž samy využívají accesorů, patří i inicializátory a metoda dealloc! Například tedy

@interface Test: ... {
  id embedded;
  void *buffer
}
// některé accesory
-(void)setEmbedded:object;
-(void)setBufferSize:(int)size;
...
@implementation Test
-init { // designovaný inicializátor
  ...
  [self setEmbedded:@"xyz"]; // embedded=@"xyz" obecně není dobře
  [self setBufferSize:1024]; // buffer=malloc(1024) obecně není dobře
  ...
}
-(void)dealloc {
  ...
  [self setEmbedded:nil]; // [embedded release] obecně není dobře
  [self setBufferSize:0]; // free(buffer) obecně není dobře
  ...
}
...

Standardní vzorce při psaní accessorů

Samozřejmě, accesory mohou obecně vypadat jakkoli – podívejte se třeba zrovna na příklad v minulém dílu našeho seriálu, kde jsme k vloženému objektu třídy NSMutableDictionary přistupovali prostřednictvím dvojice metod valueForKey: a setValue:forKey:. Nejběžnější accesory ovšem jsou ty, kde dvojice metod nabízí přístup k jedné konkrétní instanční proměnné, řekněme zhruba nějak takto:

@interface Test: ... {
  int count;
}
...
@implementation Test
...
// accesory proměnné count
-(int)count {
  return count;
}
-(void)setCount:(int)cnt {
  count=cnt;
}
...

Právě těmito accesory se nyní budeme zabývat trochu podrobněji.

Mimochodem, stojí za to si uvědomit, že pro tento jednoduchý příklad jsme celočíselnou proměnnou vůbec nevybrali náhodou: je vidět, že pokud bude accesor zajišťovat namísto jednoduchého čísla přístup ke vloženému objektu, budeme se muset postarat o správné řízení paměti, použít korektně vhodné zprávy typu retain, copy, release či autorelease. Tomu se ovšem budeme podrobně věnovat příště; dnes se soustředíme na tu nejzákladnější věc, jíž je pojmenovávání accesorů.

Co ve jméně: i pod jiným jménem...

Již jsme se o této poněkud shakespearovské tematice jednou zmiňovali, a v souvislosti s accesory je třeba se k ní znovu vrátit. Jde o to, že jakkoli růže by pod jiným jménem zajisté voněla stejně, accesory by – pokud bychom nedodrželi konvence pro jejich pojmenovávání – ani zdaleka tak dobře nefungovaly.

Proč je tomu tak? Inu, proto, že Cocoa je API velmi vysoké úrovně, a nabízí velice abstraktní služby. My si (mnohem později) tyto služby vysvětlíme podrobněji, avšak zatím se spokojíme jen s přibližnou ukázkou: jedna z mnoha možností spočívá v tom, že můžeme třeba propojit objekt "tabulka" grafického uživatelského rozhraní s datovým objektem, který tabulku obsahuje, a to jen a jenom tím, že při sestavování GUI určíme jméno, pod nímž tabulka vystupuje. Objekt grafického uživatelského rozhraní si pak na základě tohoto jména sám automaticky vyhledá odpovídající accesory (!) a vhodným způsobem je použije. Namísto několika desítek programových řádků, jež by jinak bylo zapotřebí psát a ladit, se můžeme soustředit na jiné úkoly...

Aby to ovšem mohlo správně fungovat, musíme při vymýšlení jmen accesorů dodržet několik dosti jednoduchých konvencí:

• accesory, jež vracejí hodnotu instanční proměnné (tzv. gettery), by se obecně měly jmenovat podle toho jakou hodnotu representují, bez jakéhokoli prefixu (count, filename, title, numberOfObjects, timeDelay, ...);
• výjimkou mohou být accessory, jež vracejí logické (booleovské) hodnoty: u nich může mít smysl použít prefixu is... (isHidden, isEnabled, isMainProxy, ...);
• accessory, jež hodnotu nastavují (tzv. settery), vždy mají totéž jméno jako odpovídající getter (bez případného prefixu is...), s prefixem set... Mají jeden argument, jímž je právě nastavovaná hodnota (setCount:, setFilename:, setNumberOfObjects:, setHidden:, setMainProxy:, ...);
• Settery zásadně neobsahují ověření, zda je nastavovaná hodnota validní – to patří do jiné úrovně kódu, pro toto ověřování existuje samostatný standard, jímž se budeme zabývat později.

Pokud accesory zajišťují přístup k poli hodnot – tj. getter vrací hodnotu typu NSArray, a obdobná hodnota je i argumentem setteru – nabízí Cocoa nepovinnou možnost zvýšit efektivitu doplněním několika speciálních accesorů určených právě jen pro pole objektů (pokud je neimplementujeme, vše bude fungovat stejně dobře, ale u rozsáhlých polí může být významný rozdíl v rychlosti programu):

• speciální getter s prefixem countOf... vrací počet objektů v daném poli (countOfTitles, countOfEmbeddedObjects, ...);
• speciální getter objectIn...atIndex:, jehož argumentem je číslo, vrací objekt na určené pozici (objectInTitlesAtIndex:, objectInEmbeddedObjectsAtIndex:, ...);
• pokud standardní getter (titles, embeddedObjects) vrací hodnotu třídy NSArray (tedy neměnnou), ale přitom je možné obsah pole objektů měnit, musíme implementovat speciální settery insertObject:in...atIndex: (jehož argumentem je vkládaný objekt a celé číslo) a removeObjectFrom...atIndex: (jehož argumentem je číslo). Prvý v nich vloží zadaný objekt na požadovaný index; druhý naopak objekt na zadaném indexu odstraní.