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




наследование вложенных классов c++ (7)

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

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

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

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

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

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


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

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


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


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

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

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


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

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

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


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

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






nested-class