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

Я работаю над набором классов, используемых для воспроизведения и записи видео. У меня есть один основной класс, который действует как открытый интерфейс, с такими методами, как play(), stop(), pause(), record() и т.д. Затем у меня есть классы рабочей лошади, которые выполняют декодирование видео и кодирование видео.

Я только что узнал о существовании вложенных классов в С++, и мне любопытно узнать, что программисты думают об их использовании. Я немного насторожен и не совсем уверен, какие преимущества/недостатки есть, но они кажутся (согласно книге, которую я читаю) использоваться в таких случаях, как моя.

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

Ответ 1

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

Моя философия будет заключаться в том, чтобы сделать обе структуры доступными для клиента в отполированном виде, только в предположении, что они будут использоваться в тандеме.

Я бы упомянул что-то вроде QTextDocument в Qt. Вы предоставляете прямой интерфейс для обработки данных без обработки металла, но передаете полномочия на объект, подобный QTextEdit, для выполнения манипуляции.

Ответ 2

Вы должны использовать вложенный класс для создания (малого) вспомогательного класса, который требуется для реализации основного класса. Или, например, для определения интерфейса (класс с абстрактными методами).

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

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

Ответ 3

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

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

Ответ 4

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

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

Здесь больше информации о шаблон PIMPL (раздел 3.1.1).

Ответ 5

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

Ответ 6

Иногда уместно скрыть классы реализации от пользователя - в этих случаях лучше помещать их в foo_internal.h, чем внутри определения публичного класса. Таким образом, читатели вашего foo.h не увидят, что вам не нравится, но вы все равно можете писать тесты против каждой конкретной реализации вашего интерфейса.

Ответ 7

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

Ответ 8

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

Класс вашего кодировщика/декодера звучит так, как будто он лучше подходит для Strategy Pattern

Ответ 9

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

Ответ 10

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