Мои 50 центов на это:
- Я считаю, что автор имеет в виду ситуации, когда вы не имеете определения классов в библиотеке символов, однако вы хотите создавать объекты, и передача их пользователям библиотеки (таким образом, вы являетесь владельцем памяти, общая библиотека является потребителем, но у вас нет доступа к конкретным классам внутри библиотеки)
Пример (я напишу один из вершин моя голова подчеркнуть сценарий, где это было бы полезно, тогда я напишу еще один, который я принимаю ally bumped in)
Имея динамическую библиотеку TextEditorWidgets.dll и ваше основное приложение, TextEditorWidget предоставляет абстрактный прототип TEWPrototype и заводский метод получения определенных прототипов, например, с помощью строкового идентификатора.
После фабричный метод подвергается из библиотеки DLL определяется как:
TEWPrototype* TEWPrototype::getPrototypeFor(string identifier)
{
TEWPrototype* result;
if (identifier == "SomeWidget")
{
result = ConcreteSomeWidgetPrototype;
} else if ...
return result;
}
Внутри приложения вы можете использовать следующий код:
{
vector<TEWPrototype*> allocatedWidgets;
...
TEWPrototype* SomeWidget = TEWPrototype::getPrototypeFor("SomeWidget").clone();// you are now the memory owner
allocatedWidgets.push_back(SomeWidget); // keep for deletion
TextEditorWidgetsHandle->doSomethingWithTheWidget(SomeWidget);// pass the instantiation to the consumer who knows the widget full definition
}
В приведенном выше примере, у вас есть следующие плюсы в качестве app develoer:
- вы будете контролировать то, что выделяет dll, когда и как
- вы будете управлять, если виджеты удаляются или не через всю жизнь приложения
профи, как разработчик длл:
- вы сможете добавлять новые виджеты, обеспечивая обратную функциональность
- у вас есть гарантия, что никто не будет использовать ваши внутренние функциональные возможности виджетов вне .dll
Практический пример:
Во время работы над игрой, новые объекты были созданы командой разработчиков игры, и нам нужен быстрый способ, чтобы дать конструкторам новых объекты для них, чтобы добавить в игре сцену. У нас был собственный редактор дома, поэтому у нас был контроль над инструментом проектирования.
Подход состоял в том, чтобы загрузить .dlls World Editor, а затем выставить в меню редактора, какие объекты были загружены в DLL. Редактор не знал, какие классы были внутри DLL, он знал только о том, что они имеют ничью и функцию setPosition (и некоторые другие вещи).
Когда DLL была загружена внутри редактора, имя объекта было добавлено в диспетчер прототипов объекта (в основном у нас была статическая функция getAvailableObjects и после загрузки DLL мы запросили бы это, чтобы получить строки) ,
Когда Дизайнер выбирал из меню объект (скажем, например, Crate), то был создан новый экземпляр этого объекта, который был нарисован внутри редактора, и дизайнер мог его перемещать.
Редактор не смог создать экземпляр объекта сам по себе, потому что он ничего не знал о размере объекта и о его конструкторе. Однако у нас были предварительно созданные объекты для каждого типа, которые клонировали каждый раз, когда Художник приглашал создать «новый» ящик.
В предварительном просмотре также использовались предварительно известные объекты.
Когда команда разработчиков выпустила новый набор объектов, мы просто предоставили новую dll дизайнерам, и им нужно было только «обновить» редактор BOOM: произошла волшебство: новые объекты в меню.
В качестве альтернативы абстрактная фабрика может обеспечить такую же функциональность.
Вы можете использовать конструктор, только если во время компиляции вы знаете имя класса. Одно из предпосылок для шаблона состоит в том, что вы не знаете этих имен. – molbdnilo