Dans une bibliothèque Java 7, j'ai une classe qui fournit des services à d'autres classes. Après avoir créé une instance de cette classe de service, une de ses méthodes peut être appelée plusieurs fois (appelons-la la doWork()méthode). Donc, je ne sais pas quand le travail de la classe de service est terminé.

Le problème est que la classe de service utilise des objets lourds et qu'elle devrait les libérer. J'ai mis cette partie dans une méthode (appelons-la release()), mais il n'est pas garanti que d'autres développeurs l'utilisent.

Existe-t-il un moyen de forcer les autres développeurs à appeler cette méthode après avoir terminé la tâche de classe de service? Bien sûr, je peux documenter cela, mais je veux les forcer.

Remarque: Je ne peux pas appeler la release()méthode dans la doWork()méthode, car elle a doWork() besoin de ces objets lors de son appel suivant.

La solution pragmatique consiste à faire la classe AutoCloseableet à fournir une finalize()méthode de protection (si nécessaire ... voir ci-dessous!). Ensuite, vous comptez sur les utilisateurs de votre classe pour utiliser try-with-resource ou appeler close()explicitement.

Bien sûr, je peux documenter cela, mais je veux les forcer.

Malheureusement, il n'y a aucun moyen ¹ en Java pour forcer le programmeur à faire la bonne chose. Le mieux que vous puissiez espérer est de détecter une utilisation incorrecte dans un analyseur de code statique.

Au sujet des finaliseurs. Cette fonctionnalité Java a très peu de bons cas d'utilisation. Si vous comptez sur les finaliseurs pour ranger, le problème est que cela peut prendre beaucoup de temps pour le ranger. Le finaliseur ne sera exécuté qu'une fois que le GC aura décidé que l'objet n'est plus accessible. Cela ne se produira peut-être pas tant que la machine virtuelle Java ne réalisera pas une collection complète .

Ainsi, si le problème que vous tentez de résoudre consiste à récupérer les ressources qui doivent être libérées rapidement , vous avez manqué le coche en utilisant la finalisation.

Et juste au cas où vous n’auriez pas ce que je dis plus haut ... il n’est presque jamais approprié d’utiliser des finaliseurs dans le code de production, et vous ne devriez jamais vous fier à eux!

^{1 - Il y a des façons. Si vous êtes prêt à "masquer" les objets de service du code utilisateur ou à contrôler étroitement leur cycle de vie (par exemple, https://softwareengineering.stackexchange.com/a/345100/172 ), il n'est pas nécessaire d'appeler le code utilisateur release(). Cependant, l'API devient plus compliquée, plus restreinte ... et "moche" à l'OMI. En outre, cela ne force pas le programmeur à faire ce qui est bien . Cela supprime la capacité du programmeur à faire la mauvaise chose!}

Cela ressemble au cas d' AutoCloseableutilisation de l' interface et à la try-with-resourcesdéclaration introduite dans Java 7. Si vous avez quelque chose comme:

public class MyService implements AutoCloseable {
    public void doWork() {
        // ...
    }

    @Override
    public void close() {
        // release resources
    }
}

alors vos consommateurs peuvent l'utiliser comme

public class MyConsumer {
    public void foo() {
        try (MyService myService = new MyService()) {
            //...
            myService.doWork()
            //...
            myService.doWork()
            //...
        }
    }
}

et ne pas avoir à s'inquiéter d'appeler un explicite, releaseque leur code lève une exception ou non.

Réponse supplémentaire

Si vous voulez réellement vous assurer que personne ne peut oublier d'utiliser votre fonction, vous devez faire quelques choses

1. Assurez-vous que tous les constructeurs de MyServicesont privés.
2. Définissez un point d’entrée unique à utiliser MyServicepour s’assurer qu’il est nettoyé après.

Vous feriez quelque chose comme

public interface MyServiceConsumer {
    void accept(MyService value);
}

public class MyService implements AutoCloseable {
    private MyService() {
    }


    public static void useMyService(MyServiceConsumer consumer) {
        try (MyService myService = new MyService()) {
            consumer.accept(myService)
        }
    }
}

Vous l'utiliseriez alors comme

public class MyConsumer {
    public void foo() {
        MyService.useMyService(new MyServiceConsumer() {
            public void accept(MyService myService) {
                myService.doWork()
            }
        });
    }
}

À l'origine, je ne recommandais pas ce chemin car il est affreux sans les lambdas et interfaces fonctionnelles de Java-8 (où MyServiceConsumerdevient Consumer<MyService>) et il est assez imposant pour vos consommateurs. Mais si ce que vous voulez seulement, c'est qu'il release()faille l'appeler, cela fonctionnera.

Oui, vous pouvez

Vous pouvez absolument les forcer à se libérer, et faire en sorte qu’il soit à 100% impossible à oublier, en leur rendant impossible la création de nouvelles Service instances.

S'ils ont fait quelque chose comme ça avant:

Service s = s.new();
try {
  s.doWork("something");
  if (...) s.doWork("something else");
  ...
}
finally {
  s.release(); // oops: easy to forget
}

Puis changez-le pour qu'ils puissent y accéder comme ceci.

// Their code

Service.runWithRelease(new ServiceConsumer() {
  void run(Service s) {
    s.doWork("something");
    if (...) s.doWork("something else");
    ...
  }  // yay! no s.release() required.
}

// Your code

interface ServiceConsumer {
  void run(Service s);
}

class Service {

   private Service() { ... }      // now: private
   private void release() { ... } // now: private
   public void doWork() { ... }   // unchanged

   public static void runWithRelease(ServiceConsumer consumer) {
      Service s = new Service();
      try {
        consumer.run(s);
      }
      finally {
        s.release();
      } 
    } 
  }

Mises en garde:

• Considérez ce pseudocode, cela fait longtemps que je n’ai pas écrit Java.
• Il pourrait y avoir des variantes plus élégantes de nos jours, y compris peut-être l' AutoCloseableinterface mentionnée par quelqu'un; mais l'exemple donné devrait fonctionner immédiatement, et à l'exception de l'élégance (qui est un objectif agréable en soi), il ne devrait y avoir aucune raison majeure pour le changer. Notez que cela veut dire que vous pourriez utiliser AutoCloseabledans votre implémentation privée; L'avantage de ma solution par rapport à l'utilisation de vos utilisateurs AutoCloseableest qu'elle peut, encore une fois, ne pas être oubliée.
• Vous devrez préciser si nécessaire, par exemple pour injecter des arguments dans le new Service appel.
• Comme mentionné dans les commentaires, la question de savoir si un tel construit (c'est-à-dire prendre le processus de création et de destruction d'un Service ) appartient à la main de l’appelant ou non sort du cadre de cette réponse. Mais si vous décidez que vous en avez absolument besoin, voici comment vous pouvez le faire.
• Un intervenant a fourni ces informations concernant la gestion des exceptions: Google Books.

Vous pouvez essayer d'utiliser le modèle de commande .

class MyServiceManager {

    public void execute(MyServiceTask tasks...) {
        // set up everyting
        MyService service = this.acquireService();
        // execute the submitted tasks
        foreach (Task task : tasks)
            task.executeWith(service);
        // cleanup yourself
        service.releaseResources();
    }

}

Cela vous donne un contrôle total sur l'acquisition et la libération des ressources. L'appelant ne soumet que des tâches à votre service, et vous êtes responsable de l'acquisition et du nettoyage des ressources.

Il y a un piège, cependant. L'appelant peut toujours faire ceci:

MyServiceTask t1 = // some task
manager.execute(t1);
MyServiceTask t2 = // some task
manager.execute(t2);

Mais vous pouvez résoudre ce problème quand il y a une crise. Lorsqu'il y a des problèmes de performances et que vous découvrez que certains appelants le font, montrez-leur simplement la manière appropriée et résolvez le problème:

MyServiceTask t1 = // some task
MyServiceTask t2 = // some task
manager.execute(t1, t2);

Vous pouvez rendre cette complexité arbitraire en mettant en œuvre des promesses pour des tâches qui dépendent d'autres tâches, mais la publication d'éléments devient également plus compliquée. Ceci n'est qu'un point de départ.

Async

Comme indiqué dans les commentaires, ce qui précède ne fonctionne pas vraiment avec les demandes asynchrones. C'est correct. Mais cela peut être facilement résolu dans Java 8 avec l’utilisation de CompleteableFuture , en particulier CompleteableFuture#supplyAsyncpour créer des futurs individuels et CompleteableFuture#allOfpour permettre la libération des ressources une fois que toutes les tâches sont terminées. Sinon, on peut toujours utiliser Threads ou ExecutorServices pour lancer leur propre implémentation de Futures / Promises.

Si vous le pouvez, n'autorisez pas l'utilisateur à créer la ressource. Laissez l'utilisateur passer un objet visiteur à votre méthode, ce qui créera la ressource, le transmettra à la méthode de l'objet visiteur et le libérera ensuite.

Mon idée était semblable à celle de Polygnome.

Vous pouvez avoir les méthodes "do_something ()" dans votre classe simplement ajouter des commandes à une liste de commandes privée. Ensuite, utilisez une méthode "commit ()" qui fait le travail et appelle "release ()".

Donc, si l'utilisateur n'appelle jamais commit (), le travail n'est jamais terminé. S'ils le font, les ressources sont libérées.

public class Foo
{
  private ArrayList<ICommand> _commands;

  public Foo doSomething(int arg) { _commands.Add(new DoSomethingCommand(arg)); return this; }
  public Foo doSomethingElse() { _commands.Add(new DoSomethingElseCommand()); return this; }

  public void commit() { 
     for(ICommand c : _commands) c.doWork();
     release();
     _commands.clear();
  }

}

Vous pouvez ensuite l'utiliser comme foo.doSomething.doSomethineElse (). Commit ();

Une autre alternative à celles mentionnées serait l'utilisation de "références intelligentes" pour gérer vos ressources encapsulées de manière à ce que le ramasse-miettes puisse nettoyer automatiquement sans libérer manuellement de ressources. Leur utilité dépend bien sûr de votre mise en œuvre. En savoir plus sur ce sujet dans ce merveilleux article de blog: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

Pour tout autre langage de classe, je dirais de le mettre dans le destructeur, mais comme ce n’est pas une option, je pense que vous pouvez remplacer la méthode finalize. Ainsi, lorsque l'instance sort du cadre et que les ordures sont collectées, elle sera publiée.

@Override
public void finalize() {
    this.release();
}

Je ne connais pas trop Java, mais je pense que c’est l’objectif auquel finalize () est destiné.

http://docs.oracle.com/javase/7/docs/api/java/lang/Object.html#finalize ()