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

Question

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

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

public SomeClass(String serializedString);

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

public static SomeClass toObject(String serializedString);

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

Answer 5

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

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

Answer 6

Сохранять некоторую конкретную логику (например, анализ строки) вне конструктора - это хорошая политика проектирования.

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

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