Статические методы фабрики по сравнению с Instance (нормальные) конструкторы?

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

, Например:

public class Foo
{
   private Foo() { }

   private static List<Foo> FooList = new List<Foo>();
   public static Foo CreateFoo()
   {
      Foo f = new Foo();
      FooList.Add(f);
      return f;
   }
}

, поскольку я придерживаюсь этого соглашения, если я вижу

Foo f = Foo.CreateFoo();
Bar b = new Bar();

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

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

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

http://www.cs.cmu.edu/~NatProg/papers/Ellis2007FactoryUsability.pdf

Статический метод. Тогда можно возвратить пустой указатель, вместо того, чтобы выдать исключение (если ссылочный тип)

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

Я лично предпочитаю видеть нормального конструктора, так как конструкторы должны использоваться для построения. Однако, если существует серьезное основание к не , используют один, т.е. если бы FromCharacters явно заявил, что это не выделило новую память, это стоило бы. "Новое" в вызове имеет значение.

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

Между прочим, Вы забыли другой общий падеж: пустой указатель/конструктор по умолчанию соединяется с методом инициализации.

Поскольку Jon Skeet перефразировал Josh Bloch, существует много причин, почему статический метод фабрики предпочтителен для конструктора во многих случаях. Я сказал бы, что, если класс является простым без дорогой установки или сложного использования, останьтесь с идиоматическим конструктором. Современные JVMs делают создание объекта чрезвычайно быстрым и дешевым. Если класс мог бы быть разделен на подклассы, или Вы в состоянии сделать его неизменным (большое преимущество для параллельного программирования, которое только собирается стать более важным), то пойдите с методом фабрики.

Еще одна подсказка. Не называйте метод фабрики Foo.new* или Foo.create*. Метод с этими именами должен всегда возвращать новый экземпляр, и выполнение так пропускает одно из больших преимуществ метода фабрики. Лучшее соглашение о присвоении имен Foo.of* или Foo.for*. Библиотека Google Guava (раньше Google Collections Library ) делает отличную работу по этому, по моему скромному мнению.