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

Question

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

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

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

над этим кодом:

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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

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

Answer 6

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

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

Answer 7

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

Answer 8

Для инкапсуляции создания объекта .

Answer 9

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

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