Что не так с этим кодом? создание удаляющей переменной в разных областях

Question

Я недавно видел код, похожий на тот, что описан ниже.

public void someMethod() {
  Lecture lect = createLecture();

  ...

  lect.getLectureSeries().delete();
}


public Lecture createLecture() {
  LectureSeries series = new Series();
  Lecture lect = new Lecture(series);

  ...

  return lect;
}

Дело в том, что какой-то объект (в данном случае LectureSeries), который необходимо удалить в конце вызова someMethod (), фактически создается при вызове другого метода. Я пытаюсь объяснить, почему он должен быть создан в той же области, в которой он будет удален. т.е.

public void someMethod() {
  LectureSeries series = new Series();
  Lecture lect = createLecture(series);

  ...

  series.delete();
}


public Lecture createLecture(LectureSeries series) {
  Lecture lect = new Lecture(series);

  ...

  return lect;
}

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

== Редактировать ==

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

Answer 1

Нет ничего плохого в создании объекта в методе, который выходит за рамки метода.

На языках с мусором сборка сама о себе заботится.

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

Answer 2

Вы можете использовать аргумент «Инверсия контроля». Объект Lecture нуждается в объекте LectureSeries, и этот объект лучше вводить в него, чем создавать его самому.

Внедрение зависимостей в объекты - это всегда хорошая практика. В вашем случае вы также можете сказать, что операторы создания и удаления должны быть как можно ближе. Это, безусловно, повышает удобочитаемость. В первом случае я вижу удаляемый элемент, но не вижу, где он создан. Мне нужно угадать, что элемент создается в методе создания или искать весь код, чтобы найти, где это происходит. Обработка ошибок (в случае сбоя при создании LectureSeries) также упрощается.