В большинстве определений говорится:
Абстрактный factory обеспечивает интерфейс для создания семейств связанных объектов, не указав их конкретные классы
Каково использование абстрактного шаблона factory, поскольку мы можем достичь этой задачи, создав объект конкретного класса. Почему у нас есть метод factory, который создает объект класса Concrete?
Пожалуйста, предоставьте мне какой-либо пример реальной жизни, где я должен реализовать шаблон abstractFactory?
Аннотация Factory является очень центральным шаблоном проектирования для Injection Dependency (DI). Вот список вопросов, где применение абстрактного Factory было принято в качестве решения.
Насколько я понимаю, эти вопросы представляют собой реальные проблемы или проблемы, которые у людей есть, поэтому вы должны начать с некоторых реальных примеров:
Пример реальной жизни для использования абстрактного шаблона Factory обеспечивает доступ к данным для двух разных источников данных (например, базы данных SQL и файла XML). У вас есть два разных класса доступа к данным (шлюз к хранилищу данных). Оба наследуют от базового класса, который определяет общие методы, которые должны быть реализованы (например, Load, Save, Delete).
Какой источник данных должен использоваться, не следует изменять способ, которым клиентский код извлекает его класс доступа к данным. Ваш абстрактный Factory знает, какой источник данных должен использоваться и возвращает соответствующий экземпляр по запросу. Factory возвращает этот экземпляр как тип базового класса.
Если вы правильно поняли - вопрос в том, почему у нас есть как метод Factory, так и абстрактные шаблоны Factory. Тебе нужен абстрактный Factory, когда разные полиморфные классы имеют различную процедуру создания экземпляров. И вы хотите, чтобы какой-то модуль создавал экземпляры и использовал их, не зная никаких деталей инициализации объекта. Например, вы хотите, чтобы Java-объекты выполняли некоторые вычисления. Но некоторые из них являются частью приложения, в то время как другой байт-код следует читать из БД. С другой стороны - зачем нам нужен метод Factory? Согласитесь, что абстрактный Factory перекрывает его. Но в некоторых случаях - гораздо меньше кода для написания, имея меньше классов и интерфейсов, упрощает понимание системы.
Каково использование абстрактного шаблона Factory, поскольку мы можем достичь этой задачи, создав объект конкретного класса. Почему у нас есть метод Factory, который создает объект класса Concrete?
В отсутствие Аннотация Factory, Клиент должен знать детали конкретных классов. Эта плотная связь была удалена с помощью Аннотация Factory.
Теперь Factory Метод предоставляет контракт, который должен использовать клиент. Вы можете добавить дополнительные продукты в свой Factory, добавив новые продукты, которые реализуют интерфейс, открытый методом Factory.
Обратитесь к этим связанным вопросам SE для лучшего понимания:
В чем основное отличие шаблонов Factory и Abstract Factory?
Цель:
Предоставить интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов.
С помощью sourcemaking.
Контрольный список:
Абстрактные заводы отлично подходят для поддержки нескольких платформ при сохранении единой базы кода. Предположим, у вас есть большая программа Qt или GTK + или .NET/Mono, которую вы хотите запустить в Windows, Linux и OSX. Но у вас есть функция, которая реализована по-разному на каждой платформе (возможно, через API-интерфейс kernel32 или функцию POSIX).
public abstract class Feature
{
public abstract int PlatformSpecificValue { get; }
public static Feature PlatformFeature
{
get
{
string platform;
// do platform detection here
if (platform == "Win32")
return new Win32Feature();
if (platform == "POSIX")
return new POSIXFeature();
}
}
// platform overrides omitted
}
В этом абстрактном Factory ваш пользовательский интерфейс не должен ничего знать о текущей платформе.
Feature feature = Feature.PlatformFeature;
Console.WriteLine(feature.PlatformSpecificValue);
Если вы посмотрите на шаблоны проектирования, почти все они могут быть излишними. Но какой шаблон означает широко используемый подход для решения подобных проблем. Шаблон проектирования предоставляет вам подход на уровне проекта или решение набора проблем подобного типа. Использование шаблона проектирования помогает решить вашу проблему и, следовательно, быстрее.
Это легко, если у вас есть код, который работает с абстракцией, вы должны создать абстракции, а не конкретные классы.
Вы всегда должны работать против абстракций, потому что вы можете лучше изменить код.
Это хороший пример: http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.23
Я нахожу шаблон Abstract Factory переоцененным.
Прежде всего, не так часто бывает, что у вас есть набор взаимосвязанных типов, которые вы хотите создать.
Во-вторых, уровень косвенности (абстракции), предоставляемый интерфейсами, обычно достаточен при работе с инъекцией зависимостей.
Типичный пример WindowsGui vs MacGui vs..., где у вас есть WindowsButton, MacButton, WindowsScrollBar, MacScrollbar и т.д., часто проще реализовать, определяя конкретные кнопки, полосы прокрутки и т.д. с помощью Visitor и/или Interpreter для обеспечения фактического поведения.
Чтобы ответить прямо на ваш вопрос, вы, вероятно, можете уйти, не используя такой шаблон дизайна.
Однако имейте в виду, что большинство проектов в реальном мире развиваются, и вы хотите предоставить некоторую расширяемость, чтобы сделать ваш проект надежным.
Из моего собственного опыта большую часть времени реализуется Factory, и по мере роста проекта он преобразуется в более сложные шаблоны проектирования, такие как абстрактный Factory.
Все о зависимостях. Если вам не нужны жесткие связи и зависимости, вам не нужен абстрактный factory. Но это будет иметь значение, как только вы напишете приложение, которое нуждается в обслуживании.
Предположим, вы создали a.jar, а кто-то другой использует вашу банку и хочет использовать новый конкретный объект в вашем коде. Если вы не используете абстрактный factory, то она должна изменить ваш код или перезаписать свой код. Но если вы используете абстрактный factory, то она может предоставить factory и перейти к вашему коду, и все в порядке.
Уточненная версия: Рассмотрим следующий сценарий: Кто-то написал фреймворк. В рамках структуры используется абстрактный factory и некоторые конкретные заводы для создания множества объектов во время выполнения. Таким образом, вы можете легко зарегистрировать свой собственный factory в существующую инфраструктуру и создать свои собственные объекты. Структура закрыта для модификаций и все еще легко расширяется из-за абстрактного шаблона factory.
Этот шаблон особенно полезен, когда клиент не знает точно, какого типа создать. Например, скажем, Showroom эксклюзивно продающие мобильные телефоны получают запрос для смартфонов, сделанных от Samsung. Здесь мы не знаем, какой именно тип объекта должен быть создан (при условии, что вся информация для телефона завернута в форму конкретный объект). Но мы знаем, что мы ищем смартфоны которые производятся компанией Samsung. Эта информация действительно может быть используется, если наш проект имеет абстрактную реализацию factory.
Я думаю, что есть место для абстрактного шаблона factory вместо простого шаблона factory в местах, где ваши экземпляры очень сложны, слишком сложный и уродливый для одного factory и слишком сложный для пользовательского интерфейса, чтобы понять..
Предположим, что это бренд TYPE_A, а не один класс. Предположим, что существует семейство из 100 видов подобных классов Type-A, и вам нужно создать экземпляр одного объекта из них. Представьте, что есть подробная информация, необходимая для того, чтобы сделать правильный объект из бренда многих подобных объектов, и в этом объекте объекта вам нужно точно знать, какие параметры настраивать и как их настраивать.
В специальном factory для этого бренда мы будем их дифференцировать и получить точный объект для создания экземпляра, а также как его создать. мы узнаем, что по данным сети (скажем, какой цвет доступен в интернет-магазине), а также из других приложений и служб, работающих в фоновом режиме (параметры, которые пользовательский интерфейс не знает о них).
И, может быть, завтра у нас будет еще одно семейство let, чтобы сказать type_B и type_C для создания экземпляра. Таким образом, пользовательский интерфейс будет иметь "if else", чтобы узнать, хотят ли пользователи "type_A", "type_B" или "type_C", но классы фабрик сами решат, какой класс из типа (из семейства) построить, и как настроить его - какие значения задавать его параметры или отправлять его подрядчику. Все это - по многим параметрам, которые пользовательский интерфейс не знает. Все это будет слишком много для одного класса factory.