Конструкция объекта из сериализации - что предпочтительнее?
===========================================================

Допустим, у вас есть класс `SomeClass`, который имеет собственную реализацию `toString()`, а также имеет возможность самостоятельно анализировать новый экземпляр, читая эту же строку.

Какой из этих методов вы предпочитаете или можете найти лучше?
Вы можете определить его как другой конструктор:

```
public SomeClass(String serializedString); 

```

или вы можете определить его как статический метод, который, в свою очередь, создает новый экземпляр (по одному из других конструкторов, делают некоторые с ним, и возвращают новый экземпляр:

```
public static SomeClass toObject(String serializedString); 

```

ли это еще вопрос (я подозреваю, нет ни одного случая, это дело, но я стараюсь, чтобы убедиться)

Мои собственные предпочтения, чтобы сохранить логику разбора из ряда? конструктор. Таким образом, он может вызвать соответствующий c onstructors (возможно, частные) по мере необходимости. Он не должен зависеть от конструкции объекта по умолчанию и так далее. Поэтому я бы пошел с методом toSomeClass().

Также не сразу понятно, что SomeClass (String) проанализирует объект на основе строки сериализации. Может быть много других значений для конструктора, который принимает строку. Статический метод toSomeClass() делает это понятным.



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



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

Задача конструктора - это, в основном, создание объекта. Инициализация и создание его полей.

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



Я согласен с рекомендацией Ави. Я хотел бы добавить еще два преимущества:

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

Одно из исключений: если вы пишете простой тип значения и используете неизменяемый шаблон, я не вижу причин использовать статический заводский метод.



Еще одно преимущество статического конструктора заключается в том, что вы можете дать ему содержательное имя. В этом случае, я хотел бы предложить `parse`:

```
SomeClass inst = SomeClass.parse("wibble"); 

```


Java, соглашение для таких статических методов:

```
public class Foo { 
    // ... 
    public Foo parseFoo (String s) {...} 
    // ... 
} 

```

как в стандартной `parseInt(` ...`)`, `parseLong(` ... `)`, `parseDouble(` ... `)` и т.д. К сожалению, ВС также дал нам *другое* соглашение с классами оболочек, как и в `Boolean.valueOf(` ... `)`. Однако я бы выбрал одну из этих конвенций и последовал за ней последовательно.