Конструкторы или статические методы для загрузки и сохранения объектов? - PullRequest
2 голосов
/ 22 января 2009

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

Так, скажем, для объекта Project версия экземпляра будет

public Project(path) { // Load project here }
public void Save(path) { // Save project here }

И статическая версия будет

public static Project Load(path) { // Load project and return result }
public static void Save(path, proj) { // Save project }

Итак, что вы предпочитаете?

Ответы [ 3 ]

9 голосов
/ 22 января 2009

Ни. Подумайте об извлечении логики персистентности из вашей предметной модели и в отдельный слой классов.

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

1 голос
/ 22 января 2009

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

Для загрузки лучше определить статический метод Load, если Project - абстрактный базовый класс; но в противном случае определение и вызов конструктора более идиоматичны.

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

1 голос
/ 22 января 2009

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

...