Каково практическое использование шаблона метода Factory?

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

ОТВЕТЫ

Ответ 1

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

Ответ 2

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

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

Например:

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;
  }
}

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

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

Ответ 3

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

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

Ответ 4

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

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

Ответ 5

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

Ответ 6

Шаблон factory очень полезен для сопоставления емкости с подходящим обработчиком.