Часто в документации от Qt встречается термин Pimpl. Кроме того, те кто хоть немного копался в исходном коде Qt часто видел такие макросы как: Q_DECLARE_PRIVATE, Q_D. А также встречал так называемые приватные заголовочные файлы, название которых заканчивается на "_p.h".
В этой статье я попробую приоткрыть ширму за всей это структурой.
Pimpl, что это?
Pimpl — Pointer to private implementation. Это одно из названий паттерна программирования. Еще его называют чеширским котом — «Cheshire Cat» (это название мне больше нравится). В чем суть этого паттерна? Основная идея этого паттерна — это вынести все приватные члены класса и, в не которых случаях, функционала в приватный класс.
Отсюда название «чеширский кот» — видно только улыбку, а все остальное остается невидимым, но оно несомненно есть :-) Кто не помнит этого замечательного кота, может обратится к первоисточнику, к книге Льюиса Кэрролла «Алиса в стране чудес». Очень интересная книга, особенно если читать в оригинале.
Что это дает?
Каждый из нас, конечно же, сталкивался с ситуацией, когда меню требуется сгенерировать динамически, непосредственно во время выполнения программы. Это может требоваться по разным причинам, например, из-за наличия нескольких локализаций ресурсов или из-за слишком большого разнообразия вариантов меню.
Другие названия: Bridge, Compilation Firewall, Handle/Body
Допустим, нам необходимо написать кроссплатформенное сетевое приложение с использованием сокетов. Для этого нам необходим класс GeneralSocket (“Видимый класс”), который будет инкапсулировать в себе детали реализации конкретной платформы (“Скрываемый класс”). Часто требуется скрыть детали реализации от пользователей или других разработчиков:
В первой части статьи рассматривается классическая идиома Pimpl (pointer-to-implementation, указатель на реализацию), показываются её преимущества и рассматривается дальнейшее развитие идиом на её основе. Вторая часть будет сосредоточена на том, как уменьшить недостатки, которые неизбежно возникают при использовании Pimpl.
Если вы спешите и хотите сразу перейти к решению проблемы внедрения объектов С++ в классы Objective-C без порчи заголовочных файлов, так, чтоб они могли быть включены из чистого Objective-C, вы можете прокрутить статью до заголовка Pimpl. Это решение можно использовать в ~95% случаев. Остальная часть содержит более глубокий анализ проблемы и дополнительные методы ее решения.
В первой части статьи, переведенной уважаемым skb7, было рассмотрено идиому Pimpl (pointer to implementation, указатель на реализацию), ее назначение и преимущества. Во второй части будет рассмотрено проблемы, возникающие при использовании этой идиомы, а также предложены некоторые варианты их решения.
Pimpl (pointer to implementation, указатель на имплементацию) — полезная идиома, распространенная в языке C++. У этой идиомы есть несколько положительных сторон, однако, в этой статье она рассматривается только как средство уменьшения зависимостей времени компиляции. Более подробно о самой идиоме можно посмотреть, например, здесь, здесь и здесь. Эта статья посвящена тому какой умный указатель использовать при работе с Pimpl и зачем он нужен.
Всем привет! Решил на выходных продолжить писать свой домашний проект и наступила пора реализовать платформозависимый код. Самым простым вариантом было бы описать классы в *.h файле, а в зависимости от платформы, Закрытые поля засунуть под #define. При этом, саму реализацию по конкретным платформам разнести по *.cpp файлам и включать их в компиляцию в зависимости от текущей платформы. Но... мне не нравится как выглядит описание класса с #define, поэтому я решил убрать препроцессор и оставить в описании класса только интерфейс. И да, я не пользовался абстрактными классами и pimpl, всё еще хуже :-)
