Moet ek geneste klasse in hierdie geval gebruik?

Question

Ek werk aan 'n versameling klasse wat gebruik word vir video speel en opname.Ek het een hoofklas wat optree soos die publieke koppelvlak, met metodes soos play(), stop(), pause(), record() ens...Dan het ek werkeselklasse wat die video-dekodering en video-enkodering doen.

Ek het pas geleer oor die bestaan ​​van geneste klasse in C++, en ek is nuuskierig om te weet wat programmeerders daaroor dink om dit te gebruik.Ek is 'n bietjie versigtig en nie regtig seker wat die voordele/nadele is nie, maar dit lyk of hulle (volgens die boek wat ek lees) in gevalle soos myne gebruik word.

Die boek stel voor dat in 'n scenario soos myne, 'n goeie oplossing sou wees om die werkeselklasse binne die koppelvlakklas te nes, so daar is geen aparte lêers vir klasse wat die kliënt nie bedoel is om te gebruik nie, en om enige moontlike naamkonflikte te vermy?Ek weet nie van hierdie regverdigings nie.Geneste klasse is 'n nuwe konsep vir my.Wil net sien wat programmeerders oor die probleem dink.

Answer 1

Ek sal 'n bietjie huiwerig wees om geneste klasse hier te gebruik.Wat as jy 'n abstrakte basisklas vir 'n "multimediabestuurder" geskep het om die agterkant-goed (werkesel) te hanteer, en 'n aparte klas vir die voorkantwerk?Die voorkantklas kan 'n wyser/verwysing na 'n geïmplementeerde bestuurderklas neem (vir die toepaslike mediatipe en situasie) en die abstrakte bewerkings op die werkeselstruktuur uitvoer.

My filosofie sou wees om voort te gaan en beide strukture toeganklik te maak vir die kliënt op 'n gepoleerde manier, net onder die veronderstelling dat hulle in tandem gebruik sal word.

Ek sal na iets soos a verwys QTextDocument in Qt.Jy verskaf 'n direkte koppelvlak aan die kaalmetaal-datahantering, maar gee die gesag deur na 'n voorwerp soos 'n QTextEdit om die manipulasie te doen.

Answer 2

Jy sal 'n geneste klas gebruik om 'n (klein) helperklas te skep wat nodig is om die hoofklas te implementeer.Of byvoorbeeld om 'n koppelvlak ('n klas met abstrakte metodes) te definieer.

In hierdie geval is die grootste nadeel van geneste klasse dat dit dit moeiliker maak om hulle te hergebruik.Miskien wil jy jou VideoDecoder-klas in 'n ander projek gebruik.As jy dit 'n geneste klas VideoPlayer maak, kan jy dit nie op 'n elegante manier doen nie.

Plaas eerder die ander klasse in aparte .h/.cpp-lêers, wat jy dan in jou VideoPlayer-klas kan gebruik.Die kliënt van VideoPlayer hoef nou net die lêer in te sluit wat VideoPlayer verklaar, en hoef steeds nie te weet hoe jy dit geïmplementeer het nie.

Answer 3

Een manier om te besluit of geneste klasse gebruik moet word of nie, is om te dink of hierdie klas 'n ondersteunende rol of sy eie rol speel of nie.

As dit bestaan ​​uitsluitlik met die doel om 'n ander klas te help, dan maak ek dit gewoonlik 'n geneste klas.Daar is 'n hele klomp waarskuwings daarvoor, waarvan sommige teenstrydig lyk, maar dit kom alles neer op ervaring en gevoel.

Answer 4

klink soos 'n geval waar jy die kan gebruik strategie patroon

Answer 5

Soms is dit gepas om die implementeringsklasse vir die gebruiker weg te steek -- in hierdie gevalle is dit beter om dit in 'n foo_internal.h te plaas as binne die publieke klasdefinisie.Op dié manier sal lesers van jou foo.h nie sien wat jy verkies dat hulle nie mee gepla word nie, maar jy kan steeds toetse skryf teen elk van die konkrete implementerings van jou koppelvlak.

Answer 6

Ons het 'n probleem gekry met 'n semi-oue Sun C++ samesteller en sigbaarheid van geneste klasse wat gedrag in die standaard verander het.Dit is natuurlik nie 'n rede om nie jou geneste klas te doen nie, net iets om van bewus te wees as jy van plan is om jou sagteware op baie platforms saam te stel, insluitend ou samestellers.

Answer 7

Wel, as jy wysers na jou werkperdklasse in jou koppelvlakklas gebruik en dit nie as parameters of terugkeertipes in jou koppelvlakmetodes blootstel nie, hoef jy nie die definisies vir daardie werkperde in jou koppelvlakkoplêer in te sluit nie (jy hoef net vorentoe verklaar hulle eerder).Op hierdie manier sal gebruikers van jou koppelvlak nie hoef te weet van die klasse in die agtergrond nie.

Jy hoef beslis nie klasse hiervoor te nes nie.Trouens, afsonderlike klaslêers sal jou kode eintlik baie meer leesbaar maak en makliker om te bestuur namate jou projek groei.dit sal jou ook later help as jy subklas moet maak (sê vir verskillende inhoud/kodektipes).

Hier is meer inligting oor die PIMPL patroon (afdeling 3.1.1).

Answer 8

Jy moet slegs 'n binneklas gebruik wanneer jy dit nie as 'n aparte klas kan implementeer deur die voornemende buitenste klas se publieke koppelvlak te gebruik nie.Innerlike klasse verhoog die grootte, kompleksiteit en verantwoordelikheid van 'n klas, so hulle moet spaarsamig gebruik word.

Jou enkodeerder/dekodeerderklas klink of dit beter by die Strategie patroon

Answer 9

Een rede om geneste klasse te vermy, is as jy ooit van plan is om die kode met swig (http://www.swig.org) vir gebruik met ander tale.Swig het tans probleme met geneste klasse, so interaksie met biblioteke wat enige geneste klasse blootstel, word 'n groot pyn.

Answer 10

Nog iets om in gedagte te hou, is of jy ooit verskillende implementerings van jou werkfunksies (soos dekodering en enkodering) in die vooruitsig stel.In daardie geval sal jy beslis 'n abstrakte basisklas wil hê met verskillende konkrete klasse wat die funksies implementeer.Dit sal nie regtig gepas wees om 'n aparte subklas vir elke tipe implementering te nes nie.