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

голоса
42

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

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

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

Задан 02/08/2008 в 03:51
источник пользователем
На других языках...                            


10 ответов

голоса
25

Я бы немного неохотно использовать вложенные классы здесь. Что делать, если вы создали абстрактный базовый класс для «мультимедийного драйвера», чтобы справиться с фоновой вещи (лошадки), и отдельный класс для фронтальной работы? Передний конец класс может принимать указатель / ссылку на реализованный класс драйвера (для соответствующего типа носителя и ситуации) и выполнять абстрактные операции на структуру рабочей лошади.

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

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

Ответил 02/08/2008 d 04:00
источник пользователем

голоса
9

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

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

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

Ответил 17/09/2008 d 12:50
источник пользователем

голоса
5

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

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

Ответил 05/08/2008 d 09:29
источник пользователем

голоса
4

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

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

Вот больше информации о шаблоне Pimpl (раздел 3.1.1).

Ответил 26/09/2008 d 00:34
источник пользователем

голоса
4

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

Ответил 21/09/2008 d 01:39
источник пользователем

голоса
4

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

Ответил 16/09/2008 d 10:31
источник пользователем

голоса
4

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

Ответил 05/08/2008 d 09:37
источник пользователем

голоса
2

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

Ваш класс кодер / декодер кажется, что лучше соответствует стратегии Pattern

Ответил 18/09/2008 d 16:19
источник пользователем

голоса
1

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

Ответил 23/09/2008 d 20:07
источник пользователем

голоса
1

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

Ответил 20/09/2008 d 08:37
источник пользователем

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