Ar trebui să folosesc clase imbricate în acest caz?

Aș fi puțin reticent să folosesc clase imbricate aici. Ce se întâmplă dacă ați creat o clasă abstractă de bază pentru un "driver multimedia" care să se ocupe de lucrurile de back-end (workhorse) și o clasă separată pentru munca de front-end? Clasa front-end ar putea lua un pointer / referință la o clasă de drivere implementată (pentru tipul și situația media corespunzătoare) și să efectueze operațiile abstracte pe structura căruciorului.

Filosofia mea ar fi aceea de a merge mai departe și de a le permite ambelor structuri accesibile clientului într-un mod lustruit, chiar dacă se presupune că vor fi folosite în tandem.

M-aș referi la ceva ca un QTextDocument în Qt. Oferiți o interfață directă manipulării datelor metalice goale, dar treceți autoritatea de-a lungul unui obiect ca un QTextEdit pentru a face manipularea.

sounds like a case where you could use the strategy pattern

O modalitate de a decide dacă trebuie sau nu să se utilizeze clase imbricate este să se gândească dacă această clasă joacă sau nu rolul de susținere sau de partea ei.

Dacă există doar pentru a ajuta o altă clasă, atunci în general o fac o clasă imbricată. Există o întreagă încărcătură de avertismente, dintre care unele par contradictorii, dar totul coboară la experiență și senzație de intestin.

Ei bine, dacă folosiți indicii la clasele dvs. de muncitori din clasa de interfață și nu le expuneți ca parametri sau tipuri de returnare în metodele de interfață, nu va fi necesar să includeți definițiile pentru acei cai de lucru în fișierul antetului interfeței înainte să le declare). În acest fel, utilizatorii interfeței dvs. nu vor trebui să știe despre clasele din fundal.

Cu siguranta nu trebuie sa cuiti cursuri pentru asta. De fapt, fișierele de clasă separate vor face codul mult mai ușor de citit și mai ușor de gestionat în timp ce proiectul dvs. va crește. vă va ajuta și mai târziu dacă aveți nevoie de subclase (de exemplu, pentru diferite tipuri de conținut / codec).

Iată mai multe informații despre model PIMPL (secțiunea 3.1.1).

Ar trebui să utilizați o clasă interioară numai atunci când nu o puteți implementa ca o clasă separată folosind interfața publică existentă a clasei exterioare. Clasele interioare măresc dimensiunea, complexitatea și responsabilitatea unei clase, astfel încât acestea să poată fi folosite cu ușurință.

Your encoder/decoder class sounds like it better fits the Strategy Pattern

Ați folosi o clasă imbricată pentru a crea o clasă (mică) de ajutor care este necesară pentru implementarea clasei principale. Sau, de exemplu, pentru a defini o interfață (o clasă cu metode abstracte).

În acest caz, principalul dezavantaj al claselor imbricate este că acest lucru face mai greu să le reutilizeze. Poate doriți să utilizați clasa VideoDecoder într-un alt proiect. Dacă faceți o clasă imbricată de VideoPlayer, nu puteți face acest lucru într-un mod elegant.

În schimb, puneți celelalte clase în fișiere separate .h / .cpp, pe care le puteți folosi apoi în clasa VideoPlayer. Clientul VideoPlayer trebuie să includă acum doar fișierul care declară VideoPlayer și nu are încă nevoie să știe cum îl implementați.

Uneori este recomandat să ascundeți clasele de implementare de la utilizator - în aceste cazuri este mai bine să le puneți într-un foo_internal.h decât în ​​interiorul definiției clasei publice. În acest fel, cititorii foo.h nu vor vedea ce preferați să nu fie tulburați, dar puteți scrie în continuare teste împotriva fiecărei implementări concrete a interfeței dvs.

Am apărut o problemă cu un compilator semi-vechi Sun C ++ și vizibilitatea claselor imbricate, care au schimbat comportamentul în standard. Acesta nu este un motiv pentru a nu face clasa dvs. imbricate, desigur, doar ceva pentru a fi conștienți de dacă aveți de gând pe compilarea software-ul dvs. pe o mulțime de platforme, inclusiv compilatoare vechi.

Un alt lucru pe care trebuie să-l aveți în vedere este dacă vă imaginați diferite implementări ale funcțiilor dvs. de lucru (cum ar fi decodificarea și codarea). În acest caz, ați dori cu siguranță o clasă de bază abstractă cu diferite clase concrete care pun în aplicare funcțiile. Nu ar fi cu adevărat potrivit să cuibărești o subclasă separată pentru fiecare tip de implementare.