Должны ли мы всегда использовать фабрику вместо создания объекта с помощью ключевого слова new?

Question

Я читал во многих местах, что в целом создания объектов с использованием ключевого слова 'new' следует избегать. Есть ли случай, когда создание объекта непосредственно в коде клиента - лучшая идея, чем использование фабричного класса?

Answer 1

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

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

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

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

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

Answer 2

Я читал во многих местах, что создание объекта с использованием ключевого слова 'new' следует избегать в целом

Это экстремальное видение создания объекта.
Фабричный подход (публичный static метод) следует отдавать предпочтение перед публичным конструктором в тех случаях, когда это имеет смысл.
Кроме того, в некоторых других случаях шаблон строителя является более подходящим, чем они.

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

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

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

Есть ли случаи, когда создание объекта прямо в коде клиента это лучшая идея, чем использование фабричного класса?

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

Answer 3

Метод Factory позволяет классу откладывать создание экземпляров для подклассов. Поэтому его лучше использовать, когда реализация абстрактного класса часто подвергается изменениям. Если вы не имеете дело с абстрактными классами с несколькими реализациями.