Я должен использовать вложенные классы в этом случае?

Я работаю на набор классов, используемых для воспроизведения и записи видео. У меня есть один главный класс, который действует как публичный интерфейс, с такими методами, как 
```
play()
```
, 
```
stop()
```
, 
```
pause()
```
, 
```
record()
```
 и т. д... потом у меня занятия ломовой лошади, которые делают видео декодирование и кодирование видео.
Я только что узнал о существовании вложенные классы в C , и мне интересно узнать мнение программистов об их использовании. Я немного настороженно и не совсем уверен, что преимущества/недостатки, но они кажутся (по книге, которую я читаю), чтобы использоваться в таких случаях, как мой.
Книга говорит о том, что в случае, как у меня, хорошим решением будет вложить классов рабочая лошадка внутри интерфейс класса, так что нет никаких отдельных файлах для классов клиент не предназначены в использовании, и избегать любых возможных конфликтов имен? Я не знаю об этих оправданиях. Вложенные классы-это новое понятие для меня. Просто хочу посмотреть, что программисты думают о проблеме.

Я работаю на набор классов, используемых для воспроизведения и записи видео. У меня есть один главный класс, который действует как публичный интерфейс, с такими методами, как 
```
play()
```
, 
```
stop()
```
, 
```
pause()
```
, 
```
record()
```
 и т. д... потом у меня занятия ломовой лошади, которые делают видео декодирование и кодирование видео.
Я только что узнал о существовании вложенные классы в C , и мне интересно узнать мнение программистов об их использовании. Я немного настороженно и не совсем уверен, что преимущества/недостатки, но они кажутся (по книге, которую я читаю), чтобы использоваться в таких случаях, как мой.
Книга говорит о том, что в случае, как у меня, хорошим решением будет вложить классов рабочая лошадка внутри интерфейс класса, так что нет никаких отдельных файлах для классов клиент не предназначены в использовании, и избегать любых возможных конфликтов имен? Я не знаю об этих оправданиях. Вложенные классы-это новое понятие для меня. Просто хочу посмотреть, что программисты думают о проблеме.

Я бы немного неохотно использовать вложенные классы. Что если вы создали абстрактный базовый класс для "мультимедийного" драйвер для обработки фоновых материалов (рабочая лошадка), и отдельный класс для работы? Интерфейсный класс может подвести указатель/ссылку на реализованный класс водителя (для соответствующего типа носителя и ситуации) и выполнять абстрактные операции над структурой лошадка. Моя философия должна была бы пойти дальше и сделать обе структуры доступном для клиента в более изощренных формах, только при условии, что они будут использоваться в тандеме. Я бы что-то ссылка как QTextDocument в Qt. Вы обеспечиваете прямой интерфейс к голому обработки металла, но передать власть вместе с объектом, как QTextEdit и делать манипуляции.

Вы могли бы использовать вложенный класс, чтобы создать (маленький) вспомогательный класс, который требуется для осуществления основной класс. Или например, чтобы определить интерфейс (класс с абстрактными методами). В этом случае, основным недостатком вложенных классов является то, что это делает это тяжелее, чтобы повторно использовать их. Возможно, вы захотите использовать свой класс видеодекодера в другом проекте. Если вы сделаете это вложенный класс Видеоплеер, вы не можете сделать это в элегантный способ. Вместо этого, поставить других классов в отдельных .h/.cpp файлы, которые затем можно использовать в классе Видеоплеер. Клиент Видеоплеер теперь нужно только включить файл, который объявляет видеоплеер, и еще не нужно знать о том, как вы реализовали его.

Один из способов решить, стоит ли использовать вложенные классы, чтобы думать, является ли этот класс играет вспомогательную роль или его части. Если он существует исключительно для того, чтобы помочь другой класс, то я вообще сделать это вложенный класс. Есть целая куча оговорок к этому, некоторые из которых кажутся противоречивыми, но все сводится к опыту и интуиции-чувство.

похоже на случай, когда вы могли бы использовать шаблон стратегии

Иногда это уместно, чтобы скрыть классы реализации от пользователей-в этих случаях лучше ставить их в foo\_internal.H, чем внутри определения класса. Вот кстати, читатели вашего ФОО.ч не будете видеть то, что вы предпочитаете их не беспокоить, но вы все еще можете писать тесты для каждой конкретной реализации интерфейса.

Мы попали в проблему с полу-солнце C компилятор и видимости вложенных классов, поведение изменилось в стандартных. Это не повод, чтобы не делать вложенный класс, конечно, просто что-то знать, если вы планируете компилировать свои программы на многих платформах включая старые компиляторы.

Хорошо, если вы используете указатели для вашей рабочей лошадки классов в интерфейс класса, а не выставлять их в качестве параметров или возвращаемых типов в интерфейсе методы, вы не должны включать определения этих рабочих лошадок в ваш интерфейс заголовочный файл (просто вперед объявить их вместо этого). Таким образом, пользователи вашего интерфейса не должны знать о классах в фоновом режиме. Вам наверняка не нужно классы гнездо для этого. По сути, отдельный класс файлы будет на самом деле сделать код намного более читабельным и легче управлять, как ваш проект растет. это также поможет вам позже, если вам нужно подкласс (скажем, для разных содержание/типа кодека). Вот более подробная информация о структуре интеллекту (раздел 3.1.1).

Вы должны использовать внутренний класс только тогда, когда вы не можете его реализовать как отдельный класс, используя горе-открытый интерфейс внешнего класса. Внутренние классы увеличение размера, сложности и ответственности класса, поэтому они должны использоваться экономно. Ваш кодер/декодер класс похоже, он лучше вписывается в шаблон стратегии

Одна из причин, чтобы избежать вложенных классов, если вы когда-нибудь намерены обернуть код с Свиг (<http://www.swig.org>) для использования с другими языками. В настоящее время Свиг имеет проблемы с вложенными классами, поэтому взаимодействие с библиотеками, которые предоставляют какие-либо вложенные классы, становится настоящей головной болью.