Спасибо за критику. Первые два пункта абсолютно согласен.
Вот третий — блог посвящен Qt, речь идет об внутренностях и подходах Qt и речь идет именно о чисто Qt-style подходу реализации этого паттерна. Речь идет о паттерне Pimpl d-pointer. Ввиду вышеуказанных обстоятельств можно предположить что это все касается исключительно C++ или гибридных языков, или языков которые в себя могут включать C++ (например тот же самый Objective-C).
По поводу php — я даже не знаю зачем этот паттерн там вообще нужен :-). Может потому-что я в php не силен, а может потому-что он там действительно не нужен. Интерпретатор и ABI вещи не совместимые :-)
естественно в гуи в качестве дергания свойства в ответ на реакцию нажатия — это очень гут.
А вот использовать свойства для выполнения сортировке на милионном массиве данных — не очень хорошо :-)
Всему есть свое место применения :-) Для этого думалка и нужна :-)
По поводу примера использования?
ну вот давайте на примере Qt рассмотрим.
Ребята разрабатывают библиотку или фреймворк (вернее набор библиотек, в мак ос для этого есть термин — «зонтик», а вот остальные не позаботились :-) ). Буду называть ее как одну библиотеку, пусть даже модульную.
И так они выплевывают релиз 4.0.0 — все дружно начинают присать свои приложения для него и динамически с ним линкуются. Тут выходит библиотека 4.0.1 и баз все приложения которые были собраны с предыдущей версией просто тупо падают, сегментятса или просто отказываются запускатся. В этом случае прийдется пересобирать абсолютно все приложения использующие эту библиотеку, чтобы перелинковать.
Это типо общее описание проблеммы. Qt одни из первых, кто в своих библиотеках обзаботился об ABI. Они гарантируют что все приложения собраные с любой из 4 версией библиотеку будут работать с любой другой библиотекой версии 4. Тоесть я собрал с Qt 4.6 а работать она будет с 4.1 (правда лишь в том случае, если вы не используете новые возможности, которых нет в 4.1. Но даже в этом случае можно разрулить ситуацию програмно, в Qt есть макросы чтобы узнать какой версии библиотеки сейчас в рантайме и либо сообщить юзеру что они сильно старые либо решить ту же задачу но менее оптимальным путем через другую реализацию).
Вот Pimpl для этого и нужен. Что по поводу второй части вопроса. Да конечный машинный код библиотеки изменится, но!!! ABI публичного класса останется тот же. Изменится ABI приватного, но вы же линковались с ABI публичным. Так что все нормально.
Вообще так если кратко, в любой программе (библиотека как один из вариантов) есть два интерфейса — API и ABI. Ну что такое API я думаю объяснять нет необходимости. Это функции с параметрами, переменные и тд. API используется в «Design Time» — при написании кода, а ABI в «Run Time». ABI позволяет ОС правильно запускать приложения и библиотеки и он зависит от ОС (Windows, Linux ...), архитектуры ( I386, PPC, SPARC) и от конкретной реализации (в линукс например есть две популярные реализации загрузчика — Elf и a.out, ABI у них разный). Все сказаное выше очень упрощено, в действительности все немножечко не так :-)
Ну вот начал писать и оказалось что мыслей так много что необходимо выместить их в отдельной статье.
Это значит что публичный интерфейс у нас всегда в публичном классе а свойства объекта и логика в приватном. Это можно назвать функциоанльной структуризацией. А так как у нас этих классов целая иерархия то получаем целый комплекс, который построен по общему принципу — Pimpl. Да выражение действительно у меня получилось непонятным. Подумаю как сказать проще.
Есть плюсы, есть минусы. Как минимум виджеты должны иметь их для того чтобы можно было реализовать плагин для дезайнера и для получения метаинформации из объекта.
Тка что в некоторых случаях это необходимо, но в некоторых избыточно. Как минимум это увеличивает скорость доступа к свойствам.
Если тема интересана — то попробую осветить ее поподробней.
да и плюс многие кто переходит с С++ на кьют (у нас в конторе это все «новенькие» :-) ибо на рынке труда практически нет кьют специалистов) начинают выдумывать велосипеды :-) А был один смешной кадр, он вообще заявил «без буста кодить нельзя», а когда я ему сказал что у нас на таргет платформы СТЛя нету, он был ошарашен и не мог понят как же ему теперь писать код :-) Ну в догонку можно сказать что было у него еще заявление такого рода «const — это балавство», после того как я у него поинтересовался, почему же он нехороший человек поубирал const из методов. Типа не собиралось у него :-)
хм. Вариант кстати. А если его сделать шаред. то вообще можно получить самоудаляемый синглетон.
Нада подумать на эту тему. Для малоресурсных систем достаточно актуально.
Типа не нуждается в нем никто — с глаз долой из памяти вон! :-)
Сделаю брейншторм на эту тему, может хорошый подпаттерн появится :-)
Вот тут не очень понимаю? какое преимущество в реализации синглетонов это дает?
Вот в implicit sharing например понятно: создаем копию текущего класса, а в качестве приватного берем указатель (вернее шаред указатель) на экземпляр того от которого копируемся, и держим до тех пор, пока не был вызван метод модификации, вот тогда происходит реальное копирование. Вот тут «кота» в руки, так сказать. А вот как с синглетону это поможет?
Вот третий — блог посвящен Qt, речь идет об внутренностях и подходах Qt и речь идет именно о чисто Qt-style подходу реализации этого паттерна. Речь идет о паттерне Pimpl d-pointer. Ввиду вышеуказанных обстоятельств можно предположить что это все касается исключительно C++ или гибридных языков, или языков которые в себя могут включать C++ (например тот же самый Objective-C).
По поводу php — я даже не знаю зачем этот паттерн там вообще нужен :-). Может потому-что я в php не силен, а может потому-что он там действительно не нужен. Интерпретатор и ABI вещи не совместимые :-)
А вот использовать свойства для выполнения сортировке на милионном массиве данных — не очень хорошо :-)
Всему есть свое место применения :-) Для этого думалка и нужна :-)
ну вот давайте на примере Qt рассмотрим.
Ребята разрабатывают библиотку или фреймворк (вернее набор библиотек, в мак ос для этого есть термин — «зонтик», а вот остальные не позаботились :-) ). Буду называть ее как одну библиотеку, пусть даже модульную.
И так они выплевывают релиз 4.0.0 — все дружно начинают присать свои приложения для него и динамически с ним линкуются. Тут выходит библиотека 4.0.1 и баз все приложения которые были собраны с предыдущей версией просто тупо падают, сегментятса или просто отказываются запускатся. В этом случае прийдется пересобирать абсолютно все приложения использующие эту библиотеку, чтобы перелинковать.
Это типо общее описание проблеммы. Qt одни из первых, кто в своих библиотеках обзаботился об ABI. Они гарантируют что все приложения собраные с любой из 4 версией библиотеку будут работать с любой другой библиотекой версии 4. Тоесть я собрал с Qt 4.6 а работать она будет с 4.1 (правда лишь в том случае, если вы не используете новые возможности, которых нет в 4.1. Но даже в этом случае можно разрулить ситуацию програмно, в Qt есть макросы чтобы узнать какой версии библиотеки сейчас в рантайме и либо сообщить юзеру что они сильно старые либо решить ту же задачу но менее оптимальным путем через другую реализацию).
Вот Pimpl для этого и нужен. Что по поводу второй части вопроса. Да конечный машинный код библиотеки изменится, но!!! ABI публичного класса останется тот же. Изменится ABI приватного, но вы же линковались с ABI публичным. Так что все нормально.
Вообще так если кратко, в любой программе (библиотека как один из вариантов) есть два интерфейса — API и ABI. Ну что такое API я думаю объяснять нет необходимости. Это функции с параметрами, переменные и тд. API используется в «Design Time» — при написании кода, а ABI в «Run Time». ABI позволяет ОС правильно запускать приложения и библиотеки и он зависит от ОС (Windows, Linux ...), архитектуры ( I386, PPC, SPARC) и от конкретной реализации (в линукс например есть две популярные реализации загрузчика — Elf и a.out, ABI у них разный). Все сказаное выше очень упрощено, в действительности все немножечко не так :-)
Ну вот начал писать и оказалось что мыслей так много что необходимо выместить их в отдельной статье.
doc.trolltech.com/qq/qq13-apis.html вот от бывшего троллтека документация официальня :-)
Тка что в некоторых случаях это необходимо, но в некоторых избыточно. Как минимум это увеличивает скорость доступа к свойствам.
Если тема интересана — то попробую осветить ее поподробней.
Нада подумать на эту тему. Для малоресурсных систем достаточно актуально.
Типа не нуждается в нем никто — с глаз долой из памяти вон! :-)
Сделаю брейншторм на эту тему, может хорошый подпаттерн появится :-)
Вот в implicit sharing например понятно: создаем копию текущего класса, а в качестве приватного берем указатель (вернее шаред указатель) на экземпляр того от которого копируемся, и держим до тех пор, пока не был вызван метод модификации, вот тогда происходит реальное копирование. Вот тут «кота» в руки, так сказать. А вот как с синглетону это поможет?
По поводу Q_Q — смотри пункт 9 — там он описан (Q-указатель (он же Q-pointer)).