Фабрика реализована статическим методом

Question

Я видел реализацию Factory с использованием статических методов. Примерно так:

public class MyFactory {
    public static Product1 createProduct1() {}
    public static Product2 createProduct2() {}
}

p1 = MyFactory.createProduct1();
p2 = MyFactory.createProduct2();

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

Factory factory = new MyFactory();  // might be a global or Singleton
p1 = factory.createProduct1();
p2 = factory.createProduct2();

И если я хочу изменить с MyFactory на YourFactory, то для изменения требуется только одна строка. Я также могу изменить это во время выполнения. Но возможно ли их реализовать как статический метод? Мне нужно изменить все вызовы на статическую фабрику. А также необходимо использовать проверку if-else во всех местах, если мы хотим принять решение во время выполнения.

p1 = YourFactory.createProduct1();
p2 = YourFactory.createProduct2();

Так в чем же преимущество реализации фабрики с использованием статических методов? Не теряем ли мы основной гибкости? Что я здесь пропустил?

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

Answer 1

С такими статическими методами вы получаете некоторое повторное использование кода, но это о преимуществах. Это существенно сводит шаблон oo к процедурной парадигме. Самое большое, что вы упускаете, это изменение вашей реализации во время выполнения в зависимости от контекста.

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

Самый гибкий шаблон - использовать инверсию зависимостей, то есть ваш класс зависит от фабричной абстракции и не знает, неважно, одиночный он или нет.Это позволяет учитывать контекст при поставке бетонного завода для использования.

Answer 2

Я собирался сказать, что не вижу никакой выгоды от использования этой фабрики по сравнению с созданием ваших объектов через new Product1() и т. Д.

Однако это не совсем правильно.Вы можете выбрать реализацию для базового класса, когда используете такую ​​фабрику, и это может быть причиной, по которой они ее реализовали.Например, метод createProduct1() может быть реализован как return new JumboProduct1();, где JumboProduct1 получено из Product1, а остальная часть кода будет изолирована от такого решения политики.Не очень гибко, но я думаю, что это сделало бы работу.

Answer 3

taskinoor, Использование статических методов не рекомендуется в чистом ООП программировании по нескольким причинам.

1. Невозможно добиться внедрения зависимости статическими методами.
2. Написание юнит-тестов очень сложно и практически невозможно. Лично, когда я начал программировать, я изо всех сил пытался реализовать UT со статическими методами.

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

Пожалуйста, ознакомьтесь с реализацией абстрактной фабрики здесь. Я не думаю, что для достижения абстрактной фабрики необходимо использовать «статические» методы. http://www.dofactory.com/Patterns/PatternAbstract.aspx#_self1

Answer 4

Здесь нет никаких преимуществ абстрактной фабрики. Только если этот метод является Builder - вы можете инкапсулировать некоторую условную логику в createProductX() методы.

Answer 5

Для краткости, использование статического метода для создания экземпляров объектов является наиболее подходящим, если у вас есть большое количество объектов для настройки. Например, сравнить:

textObject = new TextUI("Code Example");
textObject.move(50, 80);
textObject.size(100, 200);

и

textObject = TextUI.make("Code Example").move(50, 80).size(100, 200);

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