методы фабрики экземпляра против статических фабричных методов - PullRequest
Новая
       1

методы фабрики экземпляра против статических фабричных методов

38 голосов
/ 16 ноября 2011

Разве все фабричные методы не могут быть статичными?Нужно ли государству что-то, что производит продукт?Когда уместно использовать экземпляр фабричного или статического фабричного метода?Можете ли вы привести примеры различий между ними?

Ответы [ 5 ]

29 голосов
/ 09 декабря 2012

Предполагая, что под «методом фабрики экземпляров» вы на самом деле говорите о «фабричном методе» GoF, термин «статический фабричный метод» описан Джошуа Блохом в его книге «Эффективная Java». Погуглив, я дошел до этих сайтов:

Надеюсь, это помогло немного прояснить разницу.

Следуя совету Марво:

  • Заводской метод, как указано в GoF:

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

Пример (код Java): 

    public abstract class Product { ... }

    public class ConcreteProduct extends Product { ... }

    public abstract class Creator {
      public void anOperation() { ... product = factoryMethod(); ... }
      public abstract Product factoryMethod();
    }

    public class ConcreteCreator extends Creator {
      public Product factoryMethod() { return new ConcreteProduct(); }
    }
  • Метод статической фабрики, как указано в Effective Java:

    Класс может предоставлять открытый статический метод фабрики, который является просто статическим методом, который возвращает экземпляр класса. (...) Одним из преимуществ статических фабричных методов является то, что, в отличие от конструкторов, они имеют имена. (...) Второе преимущество статических фабричных методов состоит в том, что, в отличие от конструкторов, они не обязаны создавать новый объект каждый раз, когда они вызываются. (...) Третье преимущество статических фабричных методов заключается в том, что, в отличие от конструкторов, они могут возвращать объект любого подтипа своего возвращаемого типа. (...) Основным недостатком предоставления только статических фабричных методов является то, что классы без открытых или защищенных конструкторов не могут быть разделены на подклассы.

Пример (код Java): 

    public class Boolean {
      ...
      public static Boolean valueOf(boolean b) {
        return b ? Boolean.TRUE : Boolean.FALSE;
      }
      ...
    }
7 голосов
/ 16 ноября 2011

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

2 голосов
/ 16 ноября 2011

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

1 голос
/ 16 ноября 2011

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

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

0 голосов
/ 24 марта 2019

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

...