Alternativa pro referenci na NULL – C / C++ – Fórum – Programujte.com

 Zdravím,

pokud mám funkci, která vrací konstantní referenci na nějaký objekt

const Object &getObject() const;

tak pokud by vracela ukazatel a z libovolného důvodu by nemohla vrátit validní ukazatel, vrátila by null. Co má ale v případě chyby vracet, když její návratová hodnota je const& ? Jaký je industry standard pro tento případ?

Mám si pro každý datový typ, u nějž hrozí vrácení chyby, vytvořit nějaký dummy objekt, který by znamenal "toto je chyba" a porovnávat, zda jsou adresy stejné?

Díky za odpovědi

#2 KIIV
NullObject pattern je pro někoho až moc objektový, ale je to správné řešení.

NullObject se dobře implementuje přes Singleton.

#1 Doomista
NullObject je sice hezký, ale jeho reálné užití obecně příliš praktické není. Nebudete přece pro každé sebeprťavější rozhraní, které si v programu vytvoříte, implementovat jeho NullObject jenom proto, aby následně bylo možné ho vracet z funkcí. Je to dost pracné, a navíc naimplementovat metody rozhraní v NullObject tak, aby dávaly nějaký smysl, může být dost náročná až nemožná práce. (Pokud je nenaimplementujete, tak stejně nakonec bude muset klientský kód porovnávat je to/není to null, čímž se výhoda NullObject vzoru ztrácí.)

Řešením je, jak píše KIIV, vyhodit výjimku, pokud se skutečně jedná o chybový stav.

Pokud se nejedná o chybový stav, tedy možnost, že objekt nebude nalezený, je běžné chování, pak skutečně vracejte obyčejný ukazatel. Už samotná přítomnost ukazatele programátora nutí si uvědomit, že může dostat nullptr a popasovat se s tím. Nevím, jestli se to dá nazvat jako průmyslový standard, ale viděl jsem to všude (narozdíl od NullObject) a moje praktické zkušenosti s tím mám velmi dobré.

#4 Staon
Těch metod v rozhraní nebývá tolik, aby implementace v NullObject byla nějak významně složitá. Těch 3-5 metod se dá zvládnout docela snadno.

#5 Kit

1. Pokud implementujete jednu třídu navíc s 3 až 5 metodami pro každé rozhraní, které máte, tak je to sakra práce navíc.
2. I implementace 3 metod může být dost velký oříšek, pokud se nedá pořádně nadefinovat, co by vlastně takový neexistující objekt měl dělat. Asserty a výjimky nejsou obecně řešení, protože pak nutíte klientský kód si stejně nejdříve zjistit, zda se nejedná o NullObject (a to už si můžete rovnou porovnat normální ukazatel).
3. Jak jste přišel na to, že 3-5 metod je běžná velikost rozhraní? Ve svém okolí bych průměr hádal tak kolem 8 až 10 metod a občas jsou k vidění i rozhraní s několika desítkami metod, aniž by narušovaly Single Responsibility.

#6 Staon

1. Práce navíc u NullObject se mi projeví ušetřením na klienském kódu. V konečném důsledku ušetřím, protože klienský kód neporuší SRP.
2. Implementace běžné třídy mi obvykle zabere 1-2 hodiny včetně testů. NullObject mám naimplementovaný rychleji.
3. V rozhraní nemívám víc než 5 metod, obvykle jen 2-3. Nevidím důvod, proč by třída měla mít desítky veřejných metod. To už zavání porušením zapouzdření.

Díky za všechny názory. Staonova poznámka, že je občas celkem těžké vymyslet, co takový NullObject musí udělat, mi přijde celkem na místě, protože pokud program pokračuje dál, jako by se nechumelilo, tak by ten NullObject měl asi nějak dát najevo, že se vyskytl (aspoň error logem), a že ho tam pravděpodobně nechceme.

Házet výjimku se mi úplně nechce, v případě chybějícího klientského try and catch by ten program lehnul tak jak tak, nebo se pletu?

#8 Doomista
Spíš je otázka, co chceš aby ten NullObject dělal. Může dělat cokoli a vůbec to nemusí být chybový stav.

  Jasně, to už pak záleží na kontextu. Každopádně díky za pomoc

#7 Kit

1. Právě že obecně neušetří. Pokud budu mít nějakou vyhledávací strukturu (řekněme telefonní seznam), tak je zcela korektní a není chybovým stavem, že daný klíč v seznamu není. Daný člověk jednoduše nemá telefon. Klientský kód se v tomto případě bude skutečně chovat rozdílně pro situaci "našel" a pro situaci "nenašel" (někdy zobrazí dialog, někdy člověka přeskočí a nepošle mu spam SMS, atd.). Jak vytvoření něčeho jako NullPersonRecord v tomto případě ušetří práci? Klientský kód stejně musí výsledek nějakým způsobem porovnat a rozskočit se. Možnost, že by alternativní kód byl přímo v NullPersonRecord je čuňárna. Zaprvé porušíte single resonsibility, protože taková funkce do záznamu o uživateli logicky nepatří. Zadruhé půjde o velmi nepraktické a nerozšiřitelné řešení, protože budete muset přenést nesouvisející kód ze všech míst, která pracují s telefonním seznamem, na jedno místo.
2. Pokud se nedá pořádně určit, co by měl null object dělat, tak rozhodně to rychleji mít nebudete. Navíc jeho implementace není jediné zdržení. V C++ totiž musíte nějak zajistit vytvoření instance null object tak, aby existovala i po opuštění funkce a mohl jste ji bezpečně vrátit. Pokud to uděláte jako globální proměnnou/konstantu, tak musíte zaručit, že ji nikdo nebude chtít nikdy použít před vstupem do main, protože pořadí dynamické inicializace modulů není definované. Pokud použijete nějakou formu lazy inicializace, tak se situace zase komplikuje kvůli synchronizaci vláken. (Připouštím, že C++11 hodně pomáhá, když už má inicializaci statických proměnných ve funkci synchronizovanou. Ale podpora C++11 ještě pořád není na všech překladačích, takže když se na to spolehnete, nebudete mít přenositelný kód.)
3. Jak konkrétně bohaté rozhraní narušuje zapouzdření?

Nechápejte mě špatně, já proti NullObject nic nemám. Jsou situace, kdy se perfektně hodí a dokáže úžasným způsobem zjednodušit a zpřehlednit kód. Ale v žádném případě to není obecně platná odpověď na otázku "co vracet, pokud objekt neexistuje."

#8 Doomista
Ano, to je přesně to, co jsem měl na mysli výrokem "výjimky nepomohou." Pokud klientský kód výjimku neočekává, může to dělat pěkné brikule včetně pádu procesu.

Ale ani situace, kdy ji očekává není dobře. Vyhozená výjimka znamená chybový stav, takže se nabízí otázka, proč nevyhodit výjimku už při hledání objektu, jestliže nenalezení objektu je chybový stav. Takhle efektivně hlášení programu o chybovém stavu odsunete daleko od místa, kde k chybě skutečně došlo. A zkuste si odladit program, kde se vám chyby budou projevovat tisíce instrukcí od místa jejich vzniku 

#11 Staon

1. Pro zmíněný telefonní seznam by NullObject nedával smysl. Pokud není nalezen hledaný záznam, je vrácena prázdná kolekce, se kterou se pracuje běžným způsobem.
2. NullObject se běžně dělá jako Singleton a nikdy se nelikviduje.
3. Bohaté rozhraní obvykle porušuje zapouzdření tak, že je v něm nasekána hromada různých getterů, setterů a podobných blbostí. Rozhraní má být tenké, aby byla minimální závislost mezi třídami a třídy tak byly pokud možno snadno zaměnitelné.

#12 Staon
Výjimky běžně nechávám propadnout přes několik pater a vůbec mi to nedělá potíže s laděním aplikace. Typ a text výjimky obsahuje všechny informace, které pro její zpracování potřebuji, cestou se mi přidá i její kompletní trasa. Výjimku mohu, ale nemusím hlásit jako chybový stav - na patřičném levelu ji mohu zotavit do platného stavu (zde je prostor např. pro NullObject) a pokračovat v aplikaci.

#13 Kit

1. to je přesně to, o čem celou dobu mluvím. NullObject se hodí pouze někdy. Jsem rád, že jsme se shodli.
2. Tím, že něco pojmenujete návrhovým vzorem, nijak neodstraníte problémy, které jsem popsal. Zkoušel jste si někdy implementovat singleton s double checked locking? Není to jednoduché, snadno tam uděláte chybu, a prakticky se to nedá ladit. Navíc singleton není v tomhle případě úplně to nejlepší filozoficky. Jeho hlavním cílem je zaručit maximálně jednu instanci, ale proč by NullObject obecně nemohl mít instancí víc?
3. Nevšiml jsem si, že bych kdekoliv psal o getterech a setterech. Máte pravdu, že bohaté rozhraní může způsobovat těsné závislosti, ale vy jste mluvil o zapouzdření. Navíc ani settery a gettery zapouzdření neruší. (Čímž neříkám, že jsou dobře. Narušují něco, čemu já sám pro sebe říkám logické zapouzdření, normálně se mluví o anemických objektech.)

#14 Kit
Tady jste vůbec nepochopil, o čem píšu. Výjimky samozřejmě propadávají vertikálně přes callstack. To je jejich normální vlastnost. Já ale ukazuji, že NullObject s metodami implementovanými výjimkami, způsobuje horizontální zpoždění. Výjimka vypadne z místa, které je vzdálené od místa, kde skutečně chyba nastala. V tomto příkladu chyba nastala tehdy, když nebyl nalezený záznam pro uživatele. Ale projeví se až bůhví kde při prvním přístupu k objektu. Vy pak sice ve výjimce vidíte, že chyba nastala při volání NullObject::něco(), ale už nemáte jak dohledat, proč se vůbec stalo, že jste dostal instanci NullObject.

Výjimky mají být vždy chybový stav. Jejich použití k něčemu jinému je obvykle špatně. To že se z chyby program umí na nějaké úrovni zotavit na tom nic nemění.

Kolega právě přišel se zajímavým názorem, který se údajně (za sebe nevím, kde) často používá v std. Get funkce vrací true/false v závislosti zda (ne)našla objekt a naplní referenci, která byla předána jako parametr funkce.

#17 Doomista
to uz muzes rovnou vracet std::pair<bool, trida> ci iterator...

#17 Doomista
Tohle řešení funguje pouze pro kopírovatelné objekty a objekty které mají default konstruktor. Referenci nelze přiřadit, pouze inicializovat. Takže aby to fungovalo, musíte si nejdříve vytvořit prázdnou instanci navraceného objektu a v get metodě do ní přiřadit.

Tohle je strašně velké omezení, aby se to dalo považovat za obecně platné řešení. Automaticky jste tak totiž vyřadil objekty, které se kopírovat neumí. Což jsou například všechny polymorfní typy, které dělat kopírovatelné je cesta do pekla. Navíc u polymorfních typů dopředu nevíte, jakou konkrétní implementaci vám to vrátí, takže ani nejste schopný udělat dopředu prázdnou instanci.

std::pair asi fungovat bude, dokud si vystačíte s jeho kopírovacím konstruktorem. Jakmile budete potřebovat přiřazení, dostanete se do problému, protože reference nejde přiřazovat.

Suma sumárum, pořád se domnívám, že nejlepší obecné řešení, pokud nenalezený objekt není chyba, je vrátit ukazatel (normální nebo smart, pokud by se předávalo vlastnictví). Pokud je chyba, vracet referenci a vyhazovat výjimku.

#15 Staon

1. OK
2. NullObject sice může mít víc instancí, ale kdo potřebuje tisíce shodných objektů, když může být jeden?
3. Třídy dělám obvykle na max. 65 řádek. Řádky nepočítám, ale vychází to tak. Pokud je ve třídě příliš mnoho metod, svědčí to spíš o porušení SRP.
4. Výjimky a NullObject nekombinuji. Tady jsme se nepochopili. Psal jsem, že NullObject se dá využít k zotavení výjimky.