Vă mulțumim pentru susținere

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

Lucrez la o colecție de clase utilizate pentru redarea și înregistrarea video. Am o clasă principală care acționează ca interfața publică, cu metode precum play () , stop () , pause > record () etc ... Apoi, am cursuri de muncitori care fac decodarea video si codarea video.

Tocmai am aflat despre existența unor clase imbricate în C ++ și sunt curios să știu ce gândesc programatorii despre folosirea lor. Sunt puțin precaut și nu prea sigur care sunt avantajele / dezavantajele, dar se pare (conform cărții pe care o citesc) să fie folosit în cazuri precum a mea.

Cartea sugerează că, într-un scenariu ca al meu, o soluție bună ar fi să cuibărească clasele de muncitori din clasa de interfață, astfel încât să nu existe fișiere separate pentru clasele pe care clientul nu ar trebui să le folosească și pentru a evita eventualele conflicte de numire? Nu știu despre aceste justificări. Clasele născute sunt un nou concept pentru mine. Vrei doar să vezi ce gândesc programatorii despre problemă.

0
adăugat editat

9 răspunsuri

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.

0
adăugat

sounds like a case where you could use the strategy pattern

0
adăugat

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.

0
adăugat

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

0
adăugat

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

0
adăugat

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.

0
adăugat

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.

0
adăugat

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.

0
adăugat

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.

0
adăugat