Quel est le problème avec ce code? créer une variable de suppression dans différentes portées

Question

J'ai récemment vu du code similaire à celui décrit ci-dessous.

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

  ...

  lect.getLectureSeries().delete();
}


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

  ...

  return lect;
}

Le fait est que certains objets (dans ce cas la LectureSeries) qui doivent être supprimés à la fin de l'appel de someMethod () sont réellement créés lors de l'appel d'une autre méthode. J'essaie d'expliquer pourquoi il devrait être créé dans le même champ, il sera éventuellement supprimé. c'est-à-dire

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;
}

Le code original a entraîné certaines complications. Il est à craindre que les avantages ne soient évidents, mais est-ce que quelqu'un a des idées sur la façon dont je peux expliquer le principe plus général de cette refactorisation? ou quelqu'un veut m'expliquer pourquoi je me trompe?

== Modifier ==

Le cas en question étant une méthode de test, il était important de nettoyer tout ce qui avait été créé pendant l’exécution du test. Je pense cependant que l’effet secondaire indésirable d’une série LectureSeries créée à la suite de l’appel de createLecture () doit encore être évité dans la plupart des cas.

Answer 1

Il n’existe aucun problème inhérent à la création d’un objet dans une méthode dont la vie dépasse le cadre de la méthode.

Dans les langues à ordures ménagères, le rangement prend soin de lui-même.

Dans les langues où le programmeur doit gérer lui-même le nettoyage, il doit comprendre la propriété de l'objet qu'il reçoit de la méthode et ses tâches en matière de validation.

Answer 2

Vous pouvez utiliser l'argument de "Inversion Of Control". L’objet Lecture a besoin d’un objet LectureSeries et il est préférable de lui injecter cet objet plutôt que de le créer par lui-même.

L'injection de dépendances dans des objets est toujours une bonne pratique. En fonction de votre cas, vous pouvez également indiquer que les instructions de création et de suppression doivent être aussi proches que possible. Cela augmente certainement la lisibilité. Dans le premier cas, un élément est supprimé, mais je ne vois pas où il a été créé. Je dois deviner que l'élément est créé dans la méthode de création ou chercher dans tout le code pour trouver où cela se produit. La gestion des erreurs (en cas d'échec de la création de LectureSeries) est également simplifiée.