En una biblioteca en Java 7, tengo una clase que proporciona servicios a otras clases. Después de crear una instancia de esta clase de servicio, se puede llamar a un método varias veces (llamémoslo doWork()método). Entonces no sé cuándo se completa el trabajo de la clase de servicio.

El problema es que la clase de servicio usa objetos pesados ​​y debería liberarlos. Configuré esta parte en un método (llamémoslo release()), pero no está garantizado que otros desarrolladores utilicen este método.

¿Hay alguna manera de obligar a otros desarrolladores a llamar a este método después de completar la tarea de clase de servicio? Por supuesto que puedo documentar eso, pero quiero forzarlos.

Nota: No puedo llamar al release()método en el doWork()método, porque doWork() necesita esos objetos cuando se llama a continuación.

La solución pragmática es hacer la clase AutoCloseabley proporcionar un finalize()método como respaldo (si es apropiado ... ¡vea a continuación!). Luego confía en los usuarios de su clase para usar try-with-resource o llamar close()explícitamente.

Por supuesto que puedo documentar eso, pero quiero forzarlos.

Desafortunadamente, no hay forma ¹ en Java para obligar al programador a hacer lo correcto. Lo mejor que puede hacer es recoger el uso incorrecto en un analizador de código estático.

Sobre el tema de finalizadores. Esta característica de Java tiene muy pocos casos de buen uso. Si confía en los finalizadores para ordenar, se encuentra con el problema de que puede tomar mucho tiempo para que suceda. El finalizador solo se ejecutará después de que el GC decida que ya no se puede alcanzar el objeto. Es posible que eso no suceda hasta que JVM realice una recopilación completa .

Por lo tanto, si el problema que está tratando de resolver es recuperar los recursos que deben liberarse antes de tiempo , entonces ha perdido el bote al usar la finalización.

Y en caso de que no haya entendido lo que digo anteriormente ... ¡ casi nunca es apropiado usar finalizadores en el código de producción, y nunca debe confiar en ellos!

^{1 - Hay formas. Si está preparado para "ocultar" los objetos de servicio del código de usuario o controlar estrictamente su ciclo de vida (por ejemplo, https://softwareengineering.stackexchange.com/a/345100/172 ), entonces el código de usuario no necesita llamar release(). Sin embargo, la API se vuelve más complicada, restringida ... e IMO "fea". Además, esto no obliga al programador a hacer lo correcto . ¡Está eliminando la capacidad del programador de hacer lo incorrecto!}

Este parece ser el caso de uso de la AutoCloseableinterfaz y la try-with-resourcesdeclaración introducida en Java 7. Si tiene algo como

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

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

entonces sus consumidores pueden usarlo como

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

y no tener que preocuparse por llamar a un explícito releaseindependientemente de si su código arroja una excepción.

Respuesta adicional

Si lo que realmente está buscando es asegurarse de que nadie se olvide de usar su función, debe hacer un par de cosas

1. Asegúrese de que todos los constructores MyServicesean privados.
2. Defina un único punto de entrada para usar MyServiceque garantice que se limpie después.

Harías algo como

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

Entonces lo usarías como

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

Originalmente no recomendé esta ruta porque es horrible sin las interfaces funcionales y lambdas de Java-8 (donde se MyServiceConsumerconvierte Consumer<MyService>) y es bastante imponente para sus consumidores. Pero si lo que solo quieres es que release()te llamen, funcionará.

sí tu puedes

Puede obligarlos absolutamente a que se liberen, y hacer que sea 100% imposible de olvidar, haciendo imposible que creen nuevas Serviceinstancias.

Si hicieron algo como esto antes:

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

Luego cámbielo para que tengan acceso de esta manera.

// 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();
      } 
    } 
  }

Advertencias:

• Considere este pseudocódigo, han pasado años desde que escribí Java.
• Puede haber variantes más elegantes en estos días, tal vez incluyendo esa AutoCloseableinterfaz que alguien mencionó; pero el ejemplo dado debería funcionar fuera de la caja, y a excepción de la elegancia (que es un buen objetivo en sí mismo) no debería haber una razón importante para cambiarlo. Tenga en cuenta que esto tiene la intención de decir que puede usar AutoCloseabledentro de su implementación privada; El beneficio de mi solución sobre el uso de sus usuarios AutoCloseablees que, nuevamente, no se puede olvidar.
• Tendrá que desarrollarlo según sea necesario, por ejemplo, para inyectar argumentos en la new Servicellamada.
• Como se menciona en los comentarios, la cuestión de si una construcción como esta (es decir, tomar el proceso de crear y destruir a Service) pertenece o no a la persona que llama está fuera del alcance de esta respuesta. Pero si decides que lo necesitas absolutamente, así es como puedes hacerlo.
• Un comentarista proporcionó esta información sobre el manejo de excepciones: Google Books

Puede intentar utilizar el patrón de Comando .

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

}

Esto le brinda control total sobre la adquisición y liberación de recursos. La persona que llama solo envía tareas a su Servicio, y usted mismo es responsable de adquirir y limpiar recursos.

Sin embargo, hay una condición. La persona que llama aún puede hacer esto:

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

Pero puede abordar este problema cuando surja. Cuando haya problemas de rendimiento y descubra que algunas personas que llaman hacen esto, simplemente muéstreles la forma correcta y resuelva el problema:

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

Puede hacer esto arbitrariamente complejo implementando promesas para tareas que dependen de otras tareas, pero luego liberar cosas también se vuelve más complicado. Este es solo un punto de partida.

Asíncrono

Como se ha señalado en los comentarios, lo anterior realmente no funciona con solicitudes asincrónicas. Eso es correcto. Pero esto se puede resolver fácilmente en Java 8 con el uso de CompleteableFuture , especialmente CompleteableFuture#supplyAsyncpara crear los futuros individuales y CompleteableFuture#allOfrealizar la liberación de los recursos una vez que todas las tareas hayan finalizado. Alternativamente, uno siempre puede usar Threads o ExecutorServices para lanzar su propia implementación de Futures / Promises.

Si puede, no permita que el usuario cree el recurso. Deje que el usuario pase un objeto visitante a su método, lo que creará el recurso, lo pasará al método del objeto visitante y lo liberará después.

Mi idea era similar a la de Polygnome.

Puede tener los métodos "do_something ()" en su clase simplemente agregando comandos a una lista privada de comandos. Luego, tenga un método "commit ()" que realmente haga el trabajo y llame a "release ()".

Entonces, si el usuario nunca llama a commit (), el trabajo nunca se realiza. Si lo hacen, los recursos se liberan.

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

}

Luego puede usarlo como foo.doSomething.doSomethineElse (). Commit ();

Otra alternativa a las mencionadas sería el uso de "referencias inteligentes" para administrar sus recursos encapsulados de una manera que permita al recolector de basura limpiar automáticamente sin liberar recursos manualmente. Su utilidad depende, por supuesto, de su implementación. Lea más sobre este tema en esta maravillosa publicación de blog: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

Para cualquier otro lenguaje orientado a clases, diría que lo coloque en el destructor, pero como esa no es una opción, creo que puede anular el método de finalización. De esa manera, cuando la instancia se salga del alcance y se recolecte basura, se liberará.

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

No estoy muy familiarizado con Java, pero creo que este es el propósito para el cual finalize () está destinado.

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