Каковы практические применения Factory Method Pattern?

Question

Я довольно новичок в Design Pattern. Я только что наткнулся на Factory Design Pattern. Я понял, что это делегирует создание экземпляров подклассам. Но я не понял фактического применения шаблона. В каких сценариях этот шаблон может быть использован для хорошего эффекта. Я слышал о злоупотреблении шаблоном и не хотел бы этим заниматься. Кто-нибудь может привести пример из реальной жизни, где он обычно используется.

Answer 1

, а именно в одном из 2 случаев:

1. ваш класс не знает тип объекта, который он хочет создать, но ему просто нужен объект, который будет «выполнять работу». EMF приходит в голову, когда он интенсивно использует этот паттерн.
2. вы хотите, чтобы подклассы вашего класса определяли тип используемого объекта. то есть вы пишете свой родительский класс, не зная, какой конкретный продукт будет создан, это будет обязанностью конкретного создателя.

Answer 2

Предположим, у вас есть очередь, которая содержит объекты типа task.

Теперь вы можете создавать подклассы task по разным причинам. Если вы загружаете свои задачи из какого-либо источника, например из базы данных, вы можете использовать фабрику, чтобы определить, какой тип задачи загружать.

Например:

private IEnumerable<Task> GetTasks(DataTable Table){

  Task NewTask;

  foreach(DataRow Row in Table){
    switch(tasktype){
      case tasktypes.TaskTypeA:
        NewTask = NewTaskA(...);
        break;

      case TaskTypes.TaskTypeB:
        NewTask = NewTaskB(...);
        break;
      ...
    }

    yield return NewTask;
  }
}

Позже вы можете вызывать виртуальные методы для задач в вашей очереди, например, «потреблять» или «обрабатывать».

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

Answer 3

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

Answer 4

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

.. но есть так много вариантов использования и способов ... этот шаблон.

Answer 5

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

Answer 6

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