Factory Vs Prototype - Что использовать, когда?

Question

И Factory & Prototype помогают в создании объектов. При разработке нового приложения:

1. Когда бы вы использовали Factory Pattern поверх Prototype Pattern?
2. Когда бы вы использовали Prototype Pattern вместо Factory Pattern?

Я совершенно запутался, какой использовать где.

Я знаю, что это может быть очень специфической проблемой, но есть ли какое-то общее руководство?

Мысли?

Answer 1

Я собираюсь предположить, что вы говорите о шаблоне проектирования Abstract Factory (который не следует путать с Factory Method, который является еще одним шаблоном творческого проектирования).

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

Таким образом, прототип позволяет избежать ненужных "новых" вызовов, поскольку объекты клонируются, а не создаются. Однако в большинстве современных языков ООП я бы не сказал, что это так важно. Мои два цента: если вы действительно не видите разницы, просто продолжайте использовать тот, который вы привыкли реализовывать (то есть, вероятно, абстрактную фабрику).

Answer 2

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

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

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

Answer 3

Ну, я думаю,

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

Будучи более специфичным в фабричном методе, создание осуществляется посредством наследования, как в создании прототипа через делегирование, т.е. полиморфизм.

В моих взглядах

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

Answer 4

Прототип лучше всего рассматривать как способ оптимизации Factory (копировать вместо создания) или выполнить внедрение зависимостей (настроить фабрику для конкретной реализации / конфигурации).

Answer 5

Factory Design Patternиспользуется, когда вы хотите иметь логику, которая может предоставить вам/клиенту готовые к использованию объекты «требуемого» типа.

• Может быть более одного типа объектов (несколько производных классов от одного базового класса)
• Объект, возвращаемый методом create() класса Factory, является производным классом.
• новый объект создается с нуля при каждом запросе клиента.

On the contrary, In Prototype

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

• Объекты создаются и возвращаются с помощью метода clone().

• Возвращаемые объекты относятся к одному типу.

  Summary - To save memory & I/O required to create an object from scratch, use prototype over Factory.

Answer 6

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

• Фабричные шаблоны: иерархия классов + аргументы + программная логика -> создание экземпляров объектов
• Шаблон прототипа: иерархия классов + аргументы + логика программы -> создание экземпляра прототипа + аргументы + логика программы -> создание/клонирование объектов

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

Более подробное объяснение шаблона прототипа можно найти здесь: https://github.com/1gravity/design_patterns/tree/main/src/main/kotlin/com/onegravity/designpatterns/prototype .