Почему существуют статические методы Create?

Мне было интересно, почему существуют статические методы Create?

Например, зачем использовать этот код:

System.Xml.XmlReader reader = System.Xml.XmlReader.Create(inputUri);

по этому коду:

System.Xml.XmlReader reader = new System.Xml.XmlReader(inputUri);

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

Может ли кто-нибудь пролить свет на это?

ОТВЕТЫ

Ответ 1

XmlReader - абстрактный класс. Вы не можете его создать.

Предоставление метода Create является экземпляром шаблона factory. В зависимости от указанных аргументов выбирается и возвращается другая реализация XmlReader. Например, в платформе .NET есть проверки и недействительные реализации XmlReader.

Ответ 2

Более общий ответ...

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

Другая причина заключается в том, что метод factory действительно не нуждается в создании новых объектов - он может возвращать один и тот же снова и снова, если это необходимо.

Ответ 3

Потому что он может фактически создать и объект производного типа, что у вас нет доступа или возврата абстрактного класса (как ответ dtb). Это factory шаблон метода.

Ответ 4

Конструктор может использоваться только для создания экземпляров одного конкретного класса, тогда как статический метод Create может создавать экземпляр разных классов в зависимости от ввода.

В случае класса XmlReader метод Create возвращает XmlDictionaryReader, XmlTextReader, XmlValidatingReader или XmlNodeReader, в зависимости от используемой вами перегрузки и параметров, которые вы отправляете на нее.

Ответ 5

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

Лучшим примером является WebRequest.Create(url). В зависимости от URL, который вы передаете, вы можете получить HttpWebRequest, FtpWebRequest и т.д.

Ответ 6

  • Потому что вам не нужно фиксировать точный класс объекта, который вы получаете. Конструкторы могут создавать объекты только из одного класса.
  • Потому что вы можете дать методу содержательное имя, например. BigInt.probablePrime(). Конструкторы могут иметь только то же имя, что и класс.
  • Поскольку у вас может быть несколько методов factory для одной и той же комбинации параметров параметров, например. Point.fromPolarCoords(int, int) и Point.fromCartesianCoords(int, int), но может быть только один конструктор Point (int, int).

(Более подробный ответ дается в блохе "Эффективная Java".)

Ответ 7

Иногда они существуют как форма самодокументации. У меня есть компонент доступа к db, который я могу создать либо со строкой подключения, либо с именем соединения в файле конфигурации. Оба этих метода берут строки как параметр, поэтому их нельзя отличить только аргументами. Поэтому я создал метод FromConnectionString(string) factory и FromConnectionName(string) factory. Этот нюанс будет полностью потерян линией new Foo(bool, string).

Ответ 8

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

Мне лично не нравится этот подход, потому что он создает обратную связь в иерархии классов XmlReader. Может быть, они думали, что шаблон Factory является излишним?