В которых случаях имеет смысл использовать классы фабрики вместо статических функций?
В настоящее время я создавал класс ABCFactory, который имеет создание отдельного метода объекты ABC. Теперь, когда я думаю о нем, возможно, вместо того, чтобы иметь фабрику, я мог просто сделать статический метод в своем Методе ABC. Каково за и против при внесении этого изменения? Разве это не приведет к тому же? Я не предвижу наличие других классов, наследовали ABC, но каждый никогда не знает!
Спасибо
6 ответов
На самом деле, если вы хотите получить преимущества фабричного класса, вам понадобится статический метод в его собственном классе. Это позволит вам позже создать новые фабричные классы или перенастроить существующий, чтобы получить другое поведение. Например, один фабричный класс может создавать единорогов, реализующих интерфейс IFourHoovedAnimal. У вас может быть написан алгоритм, который работает с IFourHoovedAnimal и должен создавать их экземпляры. Позже вы можете создать новый фабричный класс, который вместо этого создает экземпляры Pegasus, которые также реализуют IFourHoovedAnimal. Старый алгоритм теперь можно повторно использовать для Pegasus, просто используя новую фабрику! Чтобы это работало, и PegasusFactory, и UnicornFactory должны наследовать от некоторого общего базового класса (обычно абстрактного класса).
Итак, вы видите, что, поместив статический метод в его собственный фабричный класс, вы можете заменить фабричные классы более новыми, чтобы повторно использовать старые алгоритмы. Это также работает для улучшения тестируемости, потому что теперь модульные тесты могут быть загружены в фабрику, которая создает фиктивные объекты.
Последнее я делал раньше (статический фабричный метод для класса, экземпляры которого вы создаете) для очень маленьких проектов, но только потому, что он мне нужен для помощи в рефакторинге старого кода, но при этом минимизирует изменения. По сути, в этом случае я выделил фрагмент кода, который создал группу элементов управления ASP.NET, и поместил все эти элементы управления в пользовательский элемент управления. Я хотел сделать свой новый пользовательский элемент управления основанным на свойстве, но для старого устаревшего кода было проще создать пользовательский элемент управления с конструктором на основе параметров.
Итак, я создал статический фабричный метод, который взял все параметры, а затем создал экземпляр пользовательского элемента управления и установил его свойства на основе параметров. В старом унаследованном коде этот статический метод использовался для создания пользовательского элемента управления, а в будущем коде вместо этого будут использоваться свойства «красивее».
Наличие единственного статического метода значительно затрудняет тестирование, тогда как наличие экземпляра объекта позволяет его легче тестировать. Кроме того, внедрение зависимостей позже станет вариантом с нестатическим решением.
Конечно, если вам это не нужно, то это нехорошие аргументы.
Для конкретных классов фабричные методы - это просто косвенный метод создания фактического типа (это не значит, что они бесполезны, но, как вы обнаружили, фабричный метод действительно может быть где угодно ).
В чем действительно проявляется фабричный метод, так это в том случае, когда ваш метод создает экземпляры типа интерфейса.
Основным преимуществом заводского метода является возможность скрыть ссылку на определенный класс за интерфейсом. Поскольку статические методы не могут быть частью интерфейса, статические фабричные методы в основном такие же, как и сам метод конструктора.Единственным полезным применением статических фабричных методов является предоставление доступа к частному конструктору - тому, что обычно используется для реализации синглтонного шаблона.
«D» в Принципах твердого объектно-ориентированного проектирования дяди Боба - это «Принцип инверсии зависимостей» Зависит от абстракций, а не от конкреций.
При крайнем соблюдении этого принципа ваш основной класс может создать все ваши фабрики, при этом каждая фабрика будет использовать другие фабрики через интерфейсы. Единственное появление «нового» (создание конкретных объектов) будет в вашем основном классе и ваших фабриках. Все ваши объекты будут работать с интерфейсами (абстракциями) с конкретными зависимостями, полученными из поставляемых фабричных реализаций.
Затем вы можете очень легко настроить или предоставить несколько основных классов, настроенных для разных сценариев.
Чрезмерное использование паттернов проектирования опасно, а креативные паттерны проектирования имеют смысл, когда у вас есть иерархия классов с определенными интерфейсами, или вам нужно построить довольно сложные объекты. Если у вас простой дизайн, используйте простые решения. Поэтому в вашем случае Factory Method будет достаточно
Да, вы правы, это еще один паттерн проектирования :)