Зачем нам нужен шаблон для заводских образцов?

Question

Большая часть определения говорит:

Абстрактная фабрика обеспечивает интерфейс для создания семейств связанных объектов без указания их конкретных классов

Что такое использование Abstract Factory Pattern как мы может достичь задачи путем создания объекта конкретного класса. Почему у нас есть заводский метод, который создает объект класса Concrete?

Просьба предоставить мне какой-либо пример реальной жизни, где я должен реализовать шаблон abstractFactory?

Answer 1

Если вы посмотрите на шаблоны проектирования, почти все они могут быть излишними. Но какой шаблон означает широко используемый подход для решения подобных проблем. Шаблон проектирования предоставляет вам подход на уровне проекта или решение набора проблем подобного типа. Использование шаблона проектирования помогает решить вашу проблему и, следовательно, быстрее.

Answer 2

Если я понимаю вас правильно - вопрос в том, почему у нас есть как метод Factory, так и абстрактные фабричные шаблоны. Вам нужна абстрактная фабрика, когда разные полиморфные классы имеют другую процедуру создания экземпляров. И вы хотите, чтобы какой-то модуль создавал экземпляры и использовал их, не зная никаких деталей инициализации объекта. Например, вы хотите, чтобы Java-объекты выполняли некоторые вычисления. Но некоторые из них являются частью приложения, тогда как байт-код другого следует читать из БД. С другой стороны - зачем нам нужен заводской метод? Согласитесь, что абстрактная фабрика перекрывает ее. Но в некоторых случаях - гораздо меньше кода для записи, имея меньше классов и интерфейсов, что упрощает понимание системы.

Answer 3

Аннотация Завод является очень центральным образцом дизайна для Инъекция зависимостей (DI). Вот список вопросов переполнения стека, где приложение Abstract Factory было принято в качестве решения.

Насколько я понимаю, эти вопросы представляют собой реальные проблемы или проблемы, которые люди имели, так что вы должны получить работу с некоторыми примерами из реальной жизни:

• Is there a pattern for initializing objects created via a DI container
• Can't combine Factory/DI
• WCF Dependency injection and abstract factory
• How to set up IoC when a key class needs Session (or other context-specific variable)
• How to Resolve type based on end-user configuration value?
• Strategy Pattern and Dependency Injection using Unity
• Abstract factory pattern on top of IoC?
• Is this the correct way to use and test a class that makes use of the factory pattern?
• DDD Book, Eric Evans: Please explain what is meant by "The FACTORY should be abstracted to the type desired rather than the concrete class(es) created."
• DI container, factory, or new for ephemeral objects?
• How to unit test instance creation?
• What is the best strategy for Dependency Injection of User Input?

Answer 4

Пример из реальной жизни для использования шаблона Abstract Factory предоставляет доступ к данным к двум различным источникам данных (например, база данных SQL и XML-файл). У вас есть два разных класса доступа к данным (шлюз к хранилищу данных). Оба наследуют от базового класса, который определяет общие методы, которые должны быть реализованы (например, Load, Save, Delete).

Какой источник данных следует использовать, не следует изменять способ получения кодом доступа к нему класса доступа к данным. Ваш абстрактный завод знает, какой источник данных должен использоваться, и возвращает соответствующий экземпляр по запросу. Завод возвращает этот экземпляр как тип базового класса.

Answer 5

Легко понять, что у вас есть код, который работает с абстракцией, вы должны создавать абстракции, а не конкретные классы.

Вы должны всегда работать против абстракций, потому что вы можете лучше изменить код.

Это хороший пример: http://en.wikipedia.org/wiki/Abstract_factory_pattern#C.23

Answer 6

Я нашел шаблон Abstract Factory переоценивать.

Прежде всего, это не произойдет , что часто, что у вас есть набор взаимосвязанных типов вы хотите создать экземпляр.

Во-вторых, уровень косвенности (абстракции), предоставляемый интерфейсами, обычно достаточен при работе с инъекцией зависимости.

Типичный пример WindowsGui против MacGui против ... где ты есть WindowsButton, MacButton, WindowsScrollBar, MacScrollbar и т.д. часто проще реализовать, определив конкретные кнопки, полосы прокрутки и т.д., используя для посетителей и/или интерпретатор, чтобы обеспечить реальное поведение.

Answer 7

Чтобы ответить прямо на ваш вопрос, вы, вероятно, можете уйти, не используя такой шаблон дизайна.

Однако имейте в виду, что большинство проектов в реальном мире развиваются, и вы хотите обеспечить какую-либо расширяемость, чтобы сделать ваш проект перспективным.

Из моего собственного опыта, в большинстве случаев, фабрика реализована, и по мере развития проекта она превращается в более сложные шаблоны проектирования, такие как абстрактная фабрика.

Answer 8

Аннотация Заводы отлично подходят для поддержки нескольких платформ при сохранении единой базы кода. Предположим, у вас есть большая программа 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 
} 

С помощью этой абстрактной фабрики ваш пользовательский интерфейс не должен ничего знать о текущей платформе.

Feature feature = Feature.PlatformFeature; 
Console.WriteLine(feature.PlatformSpecificValue); 

Answer 9

Это все о зависимостях. Если вам не нужны жесткие связи и зависимости, вам не нужна абстрактная фабрика. Но это будет иметь значение, как только вы напишете приложение, которое нуждается в обслуживании.

Answer 10

Предположим, вы создали a.jar, а кто-то другой использует вашу банку и хочет использовать новый конкретный объект в вашем коде. Если вы не используете абстрактную фабрику, она должна изменить ваш код или перезаписать свой код. Но если вы используете абстрактную фабрику, то она может предоставить фабрику и перейти к вашему коду, и все в порядке.

Уточненный вариант: Рассмотрим следующий сценарий: Кто-то другой написал фреймворк. В рамках структуры используется абстрактная фабрика и некоторые конкретные заводы для создания множества объектов во время выполнения. Таким образом, вы можете легко зарегистрировать свой собственный завод в существующей структуре и создать свои собственные объекты. Рамка закрыта для модификаций и все еще легко расширяется из-за абстрактного шаблона фабрики.

Answer 11

Использование абстрактного шаблона Factory, поскольку мы можем достичь этой задачи путем создания объекта конкретного класса. Почему у нас есть заводский метод, который создает объект класса Concrete?

В отсутствие Abstract Factory, клиент должен знать детали конкретных классов. Эта плотная муфта была удалена с помощью Abstract Factory.

Фабричный метод раскрывает договор, который клиент должен использовать. Вы можете добавить больше продуктов на свой завод, добавив новые продукты, которые реализуют интерфейс, открытый методом Factory.

Обратитесь к этим вопросам, связанным SE для лучшего понимания:

What is the basic difference between the Factory and Abstract Factory Patterns?

Намерение:

Обеспечить интерфейс для создания семейств связанных или зависимых объектов без указания их конкретных классов.

Вы можете понять Intent, структура, контрольный перечень и правила эмпирическое из Abstract Factory узор из этого sourcemaking статьи.

Контрольный список:

1. Решите, если независимость от платформы и создание служб в настоящее время являются источником боли.
2. Показать карту из платформ по сравнению с .
3. Определите заводский интерфейс , который состоит из заводского метода для каждого продукта.
4. Определить завод производный класс для каждой платформы, который инкапсулирует все ссылки на новый оператор.
5. клиент должен уйти в отставку все ссылки на новые, и использовать фабричные методы создать продукт объектов.

Answer 12

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

Understanding and Implementing Abstract Factory Pattern in C#

Answer 13

Я думаю, что есть место для абстрактной модели фабрики, а не простой шаблон завода в местах, где ваши конкретизации являются очень сложными, слишком сложны и некрасиво для одного завода и слишком сложными для пользовательского интерфейса к пониманию ..

Предположим, что это бренд TYPE_A не один класс. допустим, существует семейство из 100 видов подобных классов Type-A, и вам нужно создать экземпляр одного объекта из них. Представьте, что для того, чтобы сделать правильный объект из бренда многих подобных объектов, требуется подробная информация, и в этом объекте объекта вам нужно точно знать, какие параметры настраивать и как их настраивать.

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

И, возможно, завтра у нас будет другое семейство, скажем, type_B и type_C для создания экземпляра. Таким образом, пользовательский интерфейс будет иметь «if else», чтобы узнать, хотят ли пользователи «type_A», «type_B» или «type_C», но классы фабрик будут решать, какой именно класс следует из типа (из семейства) для сборки, и как настроить его - какие значения задавать его параметры или отправлять его подрядчику. Все это - по многим параметрам, которые пользовательский интерфейс не знает. Все это будет слишком большим для одного класса фабрики.