Powinienem użyć klas zagnieżdżonych w tym przypadku?

głosy
42

Pracuję nad kolekcją klas używanych do odtwarzania wideo i nagrywania. Mam jedną główną klasę, która działa jak interfejsie publicznym, z metod, takich jak play(), stop(), pause(), record()itd ... Potem mam lekcje koń pociągowy, które wykonują dekodowanie wideo i kodowanie wideo.

Właśnie dowiedziałem się o istnieniu klas zagnieżdżonych w C ++, a ja jestem ciekaw, co programiści myślą o ich stosowania. Jestem trochę ostrożny i nie bardzo wiadomo, jakie korzyści / wady są, ale wydają się (według książki czytam) do stosowania w takich przypadkach jak mój.

Książka sugeruje, że w scenariuszu, jak moje, dobrym rozwiązaniem byłoby gniazdo zajęcia Workhorse wewnątrz klasy interfejsu, więc nie ma oddzielnych plików dla klas klient nie jest przeznaczona do użycia, oraz w celu uniknięcia ewentualnych konfliktów nazewnictwa? Nie wiem o tych uzasadnień. Klasy zagnieżdżone są nowe pojęcie do mnie. Po prostu chcą zobaczyć, co programiści myśleć o problemie.

Utwórz 02/08/2008 o 03:51
źródło użytkownik
W innych językach...                            


10 odpowiedzi

głosy
25

Byłbym nieco niechętnie użyć klas zagnieżdżonych tutaj. Co zrobić, jeśli stworzony abstrakcyjną klasę bazową dla „kierowcy” multimedialnego do obsługi stuff back-end (Workhorse) oraz oddzielną klasę dla pracy front-end? Klasa front-end może trwać wskaźnik / odniesienia do realizowanej klasy sterownika (dla odpowiedniego typu mediów i sytuacji) i wykonywać operacje na abstrakcyjnych konstrukcji workhorse.

Moja filozofia byłoby iść do przodu i zrobić obie konstrukcje dostępne dla klienta w wypolerowanej sposób tylko przy założeniu, że będą używane w tandemie.

Chciałbym odwołać coś jak QTextDocument w Qt. Podać bezpośredni interfejs do gołego metalu przetwarzania danych, ale przekazać władzę wraz z obiektem jak QTextEdit zrobić manipulację.

Odpowiedział 02/08/2008 o 04:00
źródło użytkownik

głosy
9

Można by użyć zagnieżdżone klasy stworzyć (mały) klasy pomocnika, który jest wymagany do realizacji głównego klasy. Albo na przykład, aby zdefiniować interfejs (klasa z abstrakcyjnych metod).

W tym przypadku główną wadą klas zagnieżdżonych jest to, że sprawia, że ​​trudniej je ponownie wykorzystać. Może chcesz użyć klasy VideoDecoder w innym projekcie. Jeśli się to zagnieżdżona klasa magnetowid, nie można tego zrobić w elegancki sposób.

Zamiast umieszczać innych klas w osobnych plikach .h / .cpp, które można następnie wykorzystać w swojej klasie VideoPlayer. Klient z VideoPlayer teraz tylko musi zawierać plik, który deklaruje magnetowid, i nadal nie musi wiedzieć o tym, jak to realizowane.

Odpowiedział 17/09/2008 o 12:50
źródło użytkownik

głosy
5

Jednym ze sposobów decydowania, czy należy użyć klas zagnieżdżonych jest myśleć, czy ta klasa odgrywa rolę pomocniczą lub własną część.

Jeśli istnieje wyłącznie w celu niesienia pomocy innej klasy to ja generalnie sprawiają, że klasa zagnieżdżona. Istnieje całe obciążenie z zastrzeżeniami temu, a niektóre z nich wydają się sprzeczne, ale to wszystko sprowadza się do doświadczenia i gut-uczucie.

Odpowiedział 05/08/2008 o 09:29
źródło użytkownik

głosy
4

Cóż, jeśli używasz odnośniki do swoich klas roboczy w swojej klasie interfejs i nie wystawiać je jako parametry lub powrócić w swoim rodzaju metod interfejsu, nie będzie musiał zawierać definicje dla tych koni roboczych w pliku nagłówka interfejsu (po prostu naprzód zadeklarować je zamiast). W ten sposób, użytkownicy interfejsu nie będzie wiedzieć o zajęciach w tle.

Na pewno nie trzeba klas gniazdo dla tego produktu. W rzeczywistości, oddzielne pliki klas będzie faktycznie kod dużo bardziej czytelne i łatwiejsze do zarządzania w miarę rozwoju projektu. będzie to również pomóc później, jeśli trzeba podklasy (powiedzmy dla różnych typów treści / kodeków).

Oto więcej informacji na wzór PIMPL (sekcja 3.1.1).

Odpowiedział 26/09/2008 o 00:34
źródło użytkownik

głosy
4

Trafiliśmy problemu z pół-stary Sun kompilator C ++ i widoczności zagnieżdżonych klas, które zachowanie zmieniło się w normie. To nie jest powód, aby nie zrobić zagnieżdżone klasy, oczywiście, tylko coś mieć świadomość, jeśli plan na kompilacji oprogramowania na wielu platformach, w tym starych kompilatory.

Odpowiedział 21/09/2008 o 01:39
źródło użytkownik

głosy
4

Czasami jest to stosowne, aby ukryć klasy implementacji od użytkownika - w takich przypadkach lepiej jest umieścić je w foo_internal.h niż wewnątrz definicji klasy publicznej. W ten sposób czytelnicy Twojego Foo.h nie będzie widać, co wolisz nie trwoży one z, ale nadal można pisać testy dla każdego z konkretnych implementacji interfejsu.

Odpowiedział 16/09/2008 o 10:31
źródło użytkownik

głosy
4

brzmi jak przypadku można użyć wzoru strategii

Odpowiedział 05/08/2008 o 09:37
źródło użytkownik

głosy
2

Należy użyć wewnętrzną klasę tylko wtedy, gdy nie można wdrożyć go jako osobną klasę za pomocą niedoszły public interface class Outer. Klasy wewnętrzne zwiększyć wielkość, złożoność i odpowiedzialność klasie więc powinny być używane oszczędnie.

Klasa koder / dekoder brzmi to lepiej pasuje do strategii Wzorzec

Odpowiedział 18/09/2008 o 16:19
źródło użytkownik

głosy
1

Inną rzeczą, aby pamiętać, jest to, czy kiedykolwiek wyobrazić różne implementacje swoich funkcji pracy (takich jak dekodowanie i kodowanie). W tym przypadku, to na pewno chcesz abstrakcyjną klasę bazową z różnych klas, które realizują konkretne funkcje. Nie byłoby naprawdę być odpowiednie do gniazda osobny podklasa dla każdego typu realizacji.

Odpowiedział 23/09/2008 o 20:07
źródło użytkownik

głosy
1

Jednym z powodów, aby uniknąć zajęcia zagnieżdżonych jest jeśli kiedykolwiek zamierza zawinąć kod z łykiem ( http://www.swig.org ) do stosowania z innymi językami. SWIG obecnie ma problemy z klas zagnieżdżonych, więc relacje z bibliotek, które narażają wszelkie zagnieżdżone klasy staje się prawdziwy ból.

Odpowiedział 20/09/2008 o 08:37
źródło użytkownik

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