Bør jeg bruke nestede klasser i dette tilfellet?

stemmer
44

Jeg arbeider på en samling av klasser som brukes til video avspilling og innspilling. Jeg har en hoved klassen som virker som den felles grensesnitt, med metoder som play(), stop(), pause(), record()osv ... Så jeg har arbeidshest klasser som gjør videodekoding og videokoding.

Jeg har akkurat lært om eksistensen av nestede klasser i C ++, og jeg er glad i å vite hva programmerere tenke på å bruke dem. Jeg er litt skeptisk og ikke helt sikker på hva fordelene / ulempene er, men de synes (ifølge boken jeg leser) som skal brukes i tilfeller som mine.

Boken antyder at i en situasjon som min, ville en god løsning være å hekke arbeidshesten klassene inne i grensesnittet klassen, så det er ingen separate filer for klasser klienten er ikke ment å bruke, og for å unngå eventuelle navnekonflikter? Jeg vet ikke om disse begrunnelser. Nestede klasser er et nytt konsept for meg. Bare ønsker å se hva programmerere synes om saken.

Publisert på 02/08/2008 klokken 02:51
kilden bruker
På andre språk...                            


10 svar

stemmer
26

Jeg ville være litt motvillige til å bruke nestede klasser her. Hva om du opprettet en abstrakt base klasse for et "multimedia driver" å håndtere back-end stuff (arbeidshest), og en egen klasse for front-end arbeid? Front-end-klassen kunne ta en peker / referanse til en implementert driver klasse (for den aktuelle materialtype og situasjon), og utføre de abstrakte operasjoner på hest struktur.

Min filosofi er å gå videre og gjøre både strukturer tilgjengelig for kunden i en polert måte, bare under forutsetning av at de ville bli brukt i tandem.

Jeg vil referere til noe som en QTextDocument i Qt. Du gir et direkte grensesnitt til bart metall databehandling, men pass myndighet sammen til et objekt som en QTextEdit å gjøre manipulasjon.

Svarte 02/08/2008 kl. 03:00
kilden bruker

stemmer
9

Du vil bruke en nestet klasse for å lage en (liten) hjelper klasse som kreves for å gjennomføre den viktigste klassen. Eller for eksempel, for å definere et grensesnitt (en klasse med abstrakte metoder).

I dette tilfellet er den største ulempen med nøstede klassene at dette gjør det vanskeligere å bruke dem. Kanskje du ønsker å bruke VideoDecoder klasse i et annet prosjekt. Hvis du gjør det en nestet klasse av videospiller, kan du ikke gjøre dette på en elegant måte.

I stedet satte de andre klassene i separate .h / CPP-filer, som du deretter kan bruke i din videospiller klassen. Klienten av Videoplayer nå bare trenger å inkludere filen som erklærer videospiller, og fortsatt ikke trenger å vite om hvordan du implementert det.

Svarte 17/09/2008 kl. 11:50
kilden bruker

stemmer
5

En måte å avgjøre om ikke å bruke nestede klasser er å tenke om ikke denne klassen spiller en birolle eller sin egen del.

Hvis den finnes utelukkende i den hensikt å hjelpe en annen klasse da jeg generelt gjør det en nestet klasse. Det er en hel del begrensninger til det, noen som synes selvmotsigende, men det hele kommer ned til erfaring og gut-følelse.

Svarte 05/08/2008 kl. 08:29
kilden bruker

stemmer
4

Vel, hvis du bruker pekere til dine arbeidshest klasser i Interface klassen, og ikke utsette dem som parametere eller returtyper i grensesnittet metoder, vil du ikke trenger å ta med definisjoner for de arbeidshester i grensesnittet header filen (du bare frem erklære dem i stedet). På den måten vil brukerne av grensesnittet ikke trenger å vite om klassene i bakgrunnen.

Du definitivt ikke trenger å reir klasser for dette. Faktisk vil separate class filer faktisk gjøre koden mye mer lesbar og lettere å administrere som prosjektet vokser. det vil også hjelpe deg senere hvis du trenger å underklasse (si for forskjellige innhold / kodektyper).

Her er mer informasjon om PIMPL mønster (avsnitt 3.1.1).

Svarte 25/09/2008 kl. 23:34
kilden bruker

stemmer
4

Vi traff et problem med en semi-gamle Sun C ++ kompilatoren og synligheten av nøstede klasser som adferd endres i standarden. Dette er ikke en grunn til å ikke gjøre din nestet klasse, selvfølgelig, bare noe å være klar over hvis du har planer om å kompilere programvaren på mange plattformer, inkludert gamle kompilatorer.

Svarte 21/09/2008 kl. 00:39
kilden bruker

stemmer
4

Noen ganger er det hensiktsmessig å skjule implementerings klasser fra brukeren - i disse tilfellene er det bedre å sette dem i en foo_internal.h enn inne i public class definisjon. På den måten vil leserne av foo.h ikke se hva du foretrekker de ikke bli plaget med, men du kan fortsatt skrive tester mot hver av de konkrete implementeringer av grensesnittet.

Svarte 16/09/2008 kl. 09:31
kilden bruker

stemmer
4

høres ut som en sak der du kan bruke strategi mønster

Svarte 05/08/2008 kl. 08:37
kilden bruker

stemmer
2

Du bør bruke en indre klasse kun når du ikke kan implementere det som en egen klasse med ville være ytre klassen felles grensesnitt. Indre klasser øke størrelse, kompleksitet, og ansvaret for en klasse, så de bør brukes med måte.

Din koder / dekoder klasse høres ut som det passer bedre Strategy Pattern

Svarte 18/09/2008 kl. 15:19
kilden bruker

stemmer
1

En annen ting å huske på er om du noen gang forestille forskjellige implementasjoner av arbeidet funksjoner (for eksempel dekoding og koding). I så fall ville du definitivt vil ha en abstrakt base klasse med ulike konkrete klasser som implementerer funksjonene. Det ville virkelig ikke være hensiktsmessig å hekke en egen undergruppe for hver type gjennomføring.

Svarte 23/09/2008 kl. 19:07
kilden bruker

stemmer
1

En grunn til å unngå nøstede klassene er hvis du noen gang har tenkt å bryte koden med slurk ( http://www.swig.org ) for bruk med andre språk. Slurk har i dag problemer med nøstede klassene, så grensesnitt med biblioteker som utsetter noen nøstede klassene blir en reell smerte.

Svarte 20/09/2008 kl. 07:37
kilden bruker

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