Встраиваемые или как - не суть. Если мы создаем объект минуя фабрику, значит мы фактически признаем что никакая это не фабрика. Это ж "крах концепции", а по-простому говоря - обкакались тролли

Создание объекта по ID может быть реализовано всяко и целью фабрики не является (скорее это побочный эффект). А вот когда начинается перебор типа "тот или этот объект должен быть создан" - тогда конечно фабрика.

Так уж тяните если взялись  Изложите условия задачи здесь, подумайте как сформулировать (и не отфутболивать по ссылке), обсудим. А то выходит как-то "а у меня вот в той задаче не вышло" - ну так у всех не все выходило и что с того? Обсуждение все равно практически в тупике, так что живой пример может быть полезен.

Пытаюсь как могу

Нет, я не говорил, что не получилось. Как раз и сделал у себя в проекте реализацию фабрики. Но это оказалось медленным решением. Медленным, конечно же относительно, однако в моём случае это употребимо.

Суть задачи в обработке поступающих HTTP-запросов на сервер. Я отказался от использования одного лишь парсинга строк, поскольку хотелось максимально абстрагироваться от HTTP синтаксиса. Другими словами, на входе имеем HTTP-запрос в тексте, а на выходе - соответствующие классы самого запроса (GET, POST, HEAD и т.п.) и классы заголовков. Вот тут и поимел снижение производительности, т.к. на создание объектов классов и инициализацию их атрибутов входными значениями уходит относительно много времени. А учитывая, что поставлена задача на обработку 10000 запросов в секунду, имею не шибко нужный результат. Таким образом, традиционная фабрика, которая сейчас у меня реализована, мне не подходит по причине довольно жёстких условий задачи, хотя свою работу она выполняет вполне корректно. Поэтому я и написал свою заметку выше.

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

Запрос HTTP можно представить в виде двухуровневого дерева классов. Первый уровень - это тип/команда запроса. Второй уровень - это заголовки запроса. Чтобы было понятно, приведу простой пример запроса:
Здесь первая строка - это первый уровень. А все последующие строки - это второй уровень классов. Все они принадлежат первому уровню. Например, класс Request_GET содержит классы: Header_Host, Header_User_Agent, Header_Accept и др. Их в каждом запросе может быть довольно много. Соответственно фабрике приходится напрягаться по полной, прокручивая имеющийся у неё список возможных вариантов при каждом запросе. Потом ещё идёт инициализация вновь созданных объектов входными параметрами, проверка их корректности. И в общем-то выливается всё это в довольно длительное время.

Как-то так. Если снова написал непонятно, то наверное мне никак по другому. И, повторюсь, дело не в нежелании

Пример: есть фабрика - загрузчик файлов, напр jpg, png, bmp (для простоты). Приходит файл напр yyyyy.xxx
который надо загрузить. Если тупенько подряд пробовать все загрузчики - да, медленновато. Это Ваш случай?

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

Спасибо. Это очень похоже на то, как реализован QMetaType. Я через него сделал фабрику. Примечательно, что создание первого объекта через его метод construct() выполняется довольно медленно, а последующие вызовы идут значительно быстрее. Похоже, что кэшируются соответствия id конкретным типам классов.

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

Да, почти так я и думаю делать. Единственное, для парсинга запросов буду использовать один тред (в нём же и будет пул готовых объектов запросов и заголовков), а пул тредов уже для обработки этих запросов. Думаю, что это должно положительно сказаться на производительности. Посмотрим.

Да и пофиг на принципы. Эффективное решение задачи подчас важнее следования стандартам.

Тут не поспоришь, так и есть. QString оказался существенным тормозом. Тем более, что используемая им UTF-16 мне совершенно ни к чему. Сейчас я пока применяю QString, и кое где QStringList, но думаю впоследствии перейти либо на QByteArray, либо, если и тот не устроит, ограничиться char'ами.