Moet ik geneste klassen in dit geval?

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.

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

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.

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.

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

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.

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.

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.

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).