Mám používat vnořené třídy, v tomto případě?

hlasů
42

Já jsem pracoval na sbírce tříd používaných pro přehrávání videa a nahrávání. Mám jednu hlavní třídu, která funguje jako veřejné rozhraní, s metodami, jako je play(), stop(), pause(), record()atd ... Pak jsem dříč tříd, které se na dekódování videa a kódování videa.

Právě jsem se dozvěděl o existenci vnořených tříd v C ++, a jsem zvědavý vědět, co programátoři přemýšlet o jejich použití. Jsem trochu opatrný a ne úplně jistý, jaké jsou výhody / nevýhody jsou, ale zdá (podle knihy čtu), které mají být použity v případech, jako je ta moje.

Kniha ukazuje, že v situaci, jako je ta moje, dobrým řešením by bylo hnízdo tahoun tříd uvnitř třídy rozhraní, takže neexistují žádné samostatné soubory tříd klient není určen k použití, a aby se předešlo případným konfliktům pojmenování? Nevím o těchto důvodech. Vnořené třídy jsou nový koncept pro mě. Jen chci vidět, co programátoři přemýšlet o této otázce.

Položena 02/08/2008 v 03:51
zdroj uživatelem
V jiných jazycích...                            


10 odpovědí

hlasů
25

Byl bych trochu zdráhá použít vnořené třídy zde. Co když jste vytvořili abstraktní základní třída pro „multimediální ovladač“ zvládnout back-end věci (workhorse) a samostatnou třídu pro front-end práci? Front-end class může trvat ukazatel / odkaz na implementované třídy ovladače (pro příslušný typ média a aktuální situaci) a provést abstraktní operace na struktuře workhorse.

Moje filozofie bude pokračovat a aby obě struktury přístupné klientovi leštěné způsobem, jen za předpokladu, že by byl použit v tandemu.

Já bych odkazovat něco jako QTextDocument v Qt. Uvedete přímé rozhraní na holé manipulace kovový dat, ale předat orgánu spolu na objekt jako QTextEdit dělat manipulaci.

Odpovězeno 02/08/2008 v 04:00
zdroj uživatelem

hlasů
5

Jedním ze způsobů, rozhodování o tom, zda nepoužít vnořené třídy, je přemýšlet, zda tato třída hraje podpůrnou roli, nebo je to vlastní část.

Pokud existuje pouze za účelem pomoci jinou třídu pak jsem obvykle dělat to vnořené třídy. Existuje celá zatížení výhradami k tomu, z nichž některé se zdají protichůdné, ale to všechno přijde na zkušenosti a gut-pocit.

Odpovězeno 05/08/2008 v 09:29
zdroj uživatelem

hlasů
4

Zní to jako případ, kdy by bylo možné použít strategii vzor

Odpovězeno 05/08/2008 v 09:37
zdroj uživatelem

hlasů
4

Někdy je vhodné skrýt implementační třídy od uživatele - v těchto případech je lepší dát v foo_internal.h než uvnitř definice public class. Tímto způsobem budou čtenáři vašeho foo.h nevidí, co byste raději neměly být trápí se, ale stále můžete psát testy proti každému z konkrétních implementací svého rozhraní.

Odpovězeno 16/09/2008 v 10:31
zdroj uživatelem

hlasů
9

Použili byste vnořené třídu k vytvoření (malý) pomocnou třídu, která je potřebné k realizaci hlavní třídu. Nebo například pro definování rozhraní (třídu s abstraktní metody).

V tomto případě je hlavní nevýhodou vnořených tříd je, že to dělá to těžší znovu použít. Možná budete chtít používat svůj VideoDecoder třídu v jiném projektu. Pokud jste to vnořená třída VideoPlayer dělat, můžete to udělat v elegantním způsobem.

Místo toho, dát další třídy v samostatných .h / cpp soubory, které pak můžete použít ve své třídě VideoPlayer. Klientem VideoPlayer nyní pouze musí obsahovat soubor, který prohlašuje videoplayer, a přesto nemusí vědět o tom, jak ji realizovat.

Odpovězeno 17/09/2008 v 12:50
zdroj uživatelem

hlasů
2

Měli byste použít vnitřní třídu jen tehdy, když jej nelze realizovat jako samostatné třídy pomocí rádoby veřejné rozhraní vnějším třídy. Vnitřní třídy zvýšit velikost, složitost a odpovědnost třídy, takže by měly být používány šetrně.

Váš kodér / dekodér třída vypadá lépe zapadá do strategie Pattern

Odpovězeno 18/09/2008 v 16:19
zdroj uživatelem

hlasů
1

Jedním z důvodů, aby se zabránilo vnořené třídy je, pokud jste někdy v úmyslu zabalit kód s douškem ( http://www.swig.org ) pro použití s jinými jazyky. Swig má v současné době problémy s vnořených tříd, takže propojení s knihovnami, které vystavují jakékoliv vnořené třídy stává skutečnou bolest.

Odpovězeno 20/09/2008 v 08:37
zdroj uživatelem

hlasů
4

Narazili jsme problém s semi-old Sun C ++ kompilátoru a viditelnost vnořených tříd, které změnily chování v normě. To není důvod, aby to dělat svou vnořené třídy, samozřejmě, prostě něco, být si vědom, pokud máte v plánu na kompilaci software na mnoha platformách včetně starých překladačů.

Odpovězeno 21/09/2008 v 01:39
zdroj uživatelem

hlasů
1

Další věc, kterou byste měli mít na paměti, je to, zda jste si někdy představit různé implementace svých pracovních funkcí (jako je dekódování a kódování). V takovém případě byste určitě chtít abstraktní základní třídy s různými konkrétními třídami, které realizují funkce. Nebylo by to být opravdu vhodné hnízdo samostatné podtřídy pro každý typ implementace.

Odpovězeno 23/09/2008 v 20:07
zdroj uživatelem

hlasů
4

No, pokud budete používat odkazy na vaše dříč tříd ve své třídě rozhraní a nevystavujte je jako parametry nebo vrátit typy ve svých metodách rozhraní, nebudete muset zahrnout definice těchto pracovních koní v souboru záhlaví rozhraní (stačí vpřed deklarovat místo). Tímto způsobem budou uživatelé vaší rozhraní nemusí vědět o třídách v pozadí.

Ty určitě nemusíte hnízda tříd pro toto. Ve skutečnosti bude samostatné soubory tříd vlastně váš kód mnohem čitelnější a snadněji spravovat, jak váš projekt roste. to vám také pomůže později, pokud potřebujete podtřídy (řekněme pro různé typy obsahu / kodeků).

Zde je více informací o PIMPL vzoru (bod 3.1.1).

Odpovězeno 26/09/2008 v 00:34
zdroj uživatelem

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more