Moet ik geneste klassen in dit geval?

stemmen
42

Ik ben bezig met een verzameling van klassen die worden gebruikt voor het afspelen van video en opnemen. Ik heb één hoofdklasse die fungeert als de openbare interface, met methoden zoals play(), stop(), pause(), record()etc ... Dan heb ik werkpaard branches die de video-decodering en video encoding doen.

Ik net geleerd over het bestaan ​​van geneste klassen in C ++, en ik ben benieuwd om te weten wat programmeurs denken over het gebruik ervan. Ik ben een beetje oppassen en niet helemaal zeker wat de voordelen / nadelen zijn, maar ze lijken (volgens het boek dat ik aan het lezen ben) om te worden gebruikt in gevallen zoals de mijne.

Het boek suggereert dat in een scenario als de mijne, zou een goede oplossing zijn om het nest van de werkpaard klassen binnen de interface klasse, dus er zijn geen aparte bestanden voor de klassen van de cliënt is niet bedoeld om te gebruiken, en om eventuele naamgeving conflicten te vermijden? Ik weet niet over deze rechtvaardigingen. Geneste klassen zijn een nieuw concept voor mij. Ik wil gewoon om te zien wat programmeurs na te denken over de kwestie.

De vraag is gesteld op 02/08/2008 om 03:51
bron van user
In andere talen...                            


10 antwoorden

stemmen
25

Ik zou een beetje terughoudend om geneste klassen hier te gebruiken. Wat als u een abstracte basisklasse gemaakt voor een "multimedia driver" om de back-end stuff (werkpaard) en een aparte klasse handgreep voor de front-end werk? De front-end klasse kan een pointer / verwijzing naar een uitvoering stuurprogrammaklasse (het juiste mediatype en situatie) overnemen en de abstracte bewerkingen op het werkpaard structuur.

Mijn filosofie zou zijn om verder te gaan en maak beide structuren toegankelijk zijn voor de klant in een gepolijste manier, net onder de veronderstelling dat ze zouden worden gebruikt in tandem.

Ik zou iets te verwijzen als een QTextDocument in Qt. U zorgt voor een directe interface naar de kale handling metal gegevens, maar langs de instantie mee naar een voorwerp, zoals een QTextEdit om de manipulatie te doen.

antwoordde op 02/08/2008 om 04:00
bron van user

stemmen
5

Een manier om te beslissen al dan niet geneste klassen is om na te denken of deze klasse een ondersteunende rol speelt of zijn eigen deel.

Als het uitsluitend bestaat voor het doel van het helpen van een andere klasse dan ik maak er een geneste klasse in het algemeen. Er zijn een hele lading van kanttekeningen die, waarvan sommige tegenstrijdig lijken, maar het komt allemaal neer op ervaring en gut-gevoel.

antwoordde op 05/08/2008 om 09:29
bron van user

stemmen
4

klinkt als een geval waar je het zou kunnen gebruiken strategie patroon

antwoordde op 05/08/2008 om 09:37
bron van user

stemmen
4

Soms is het aangewezen om de uitvoering klassen verbergen voor de gebruiker - in deze gevallen is het beter om ze in een foo_internal.h dan binnen de public class definitie. Op die manier zullen de lezers van uw foo.h niet zien wat je liever dat ze geen last van, maar je kunt nog steeds schrijven testen tegen elk van de beton implementaties van de interface.

antwoordde op 16/09/2008 om 10:31
bron van user

stemmen
9

Je zou een geneste klasse te gebruiken om een ​​(kleine) helper klasse die er nodig is om de uitvoering van de belangrijkste klasse te maken. Of bijvoorbeeld, een interface (een klasse met abstracte methoden) te definiëren.

In dit geval is het belangrijkste nadeel van geneste klassen is dat dit maakt het moeilijker om opnieuw te gebruiken. Misschien kunt u graag uw VideoDecoder klasse te gebruiken in een ander project. Als je het een geneste klasse VideoPlayer maken, kunt u dit niet doen op een elegante manier.

In plaats daarvan, zet de andere klassen in aparte .h / .cpp bestanden, die u vervolgens kunt gebruiken in uw klasse VideoPlayer. De cliënt van VideoPlayer nu hoeft alleen het bestand dat VideoPlayer verklaart onder andere, en nog steeds niet moet weten over hoe je het geïmplementeerd.

antwoordde op 17/09/2008 om 12:50
bron van user

stemmen
2

Je moet een innerlijke klasse alleen gebruiken wanneer je niet kunt implementeren als een aparte klasse met behulp van de zogenaamde openbare interface buitenste class'. Inner klassen verhoging van de omvang, complexiteit, en de verantwoordelijkheid van een klasse, zodat ze spaarzaam moeten worden gebruikt.

Uw encoder / decoder klasse klinkt alsof het beter past bij de strategie Pattern

antwoordde op 18/09/2008 om 16:19
bron van user

stemmen
1

Een van de redenen om geneste klassen te voorkomen is als je ooit van plan om de code met slok (wrap http://www.swig.org ) voor gebruik met andere talen. Swig heeft op dit moment problemen met geneste klassen, dus interfacing met bibliotheken die bloot elke geneste klassen wordt het een echte pijn.

antwoordde op 20/09/2008 om 08:37
bron van user

stemmen
4

We slaan een probleem met een semi-oude Zon C ++ compiler en de zichtbaarheid van geneste klassen die het gedrag veranderd in de standaard. Dit is geen reden om uw geneste klasse niet, natuurlijk, gewoon iets om in de gaten als u van plan op het samenstellen van uw software op tal van platforms, waaronder oude compilers.

antwoordde op 21/09/2008 om 01:39
bron van user

stemmen
1

Een ander ding in gedachten te houden is de vraag of je ooit voor ogen verschillende implementaties van je werk functies (zoals decodering en codering). In dat geval zou u zeker wilt een abstracte basisklasse met verschillende concrete klassen waarin de functies te implementeren. Het zou niet echt geschikt om te nestelen zijn een aparte subklasse voor elk type van de uitvoering.

antwoordde op 23/09/2008 om 20:07
bron van user

stemmen
4

Nou, als je verwijzingen naar uw werkpaard klassen in uw Interface klas en ze niet bloot als parameters of return typen in de interface methoden, zult u niet nodig om de definities voor de werkpaarden in de interface header bestand op te nemen (je gewoon forward verklaren hen in plaats). Op die manier zullen de gebruikers van de interface niet moet weten over de klassen in de achtergrond.

Je zeker niet hoeft te nest klassen voor dit. In feite zal een aparte klasse bestanden daadwerkelijk uw code veel beter leesbaar en eenvoudiger te beheren als uw project groeit. het zal u ook helpen later op als je nodig hebt om een ​​subklasse (zeg voor verschillende soorten content / codec).

Hier vindt u meer informatie over de PIMPL patroon (paragraaf 3.1.1).

antwoordde op 26/09/2008 om 00:34
bron van user

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