In una libreria in Java 7, ho una classe che fornisce servizi ad altre classi. Dopo aver creato un'istanza di questa classe di servizio, un suo metodo può essere chiamato più volte (chiamiamolo il doWork()metodo). Quindi non so quando il lavoro della classe di servizio è completato.

Il problema è che la classe di servizio utilizza oggetti pesanti e dovrebbe rilasciarli. Ho impostato questa parte in un metodo (chiamiamolo release()), ma non è garantito che altri sviluppatori useranno questo metodo.

C'è un modo per costringere altri sviluppatori a chiamare questo metodo dopo aver completato l'attività della classe di servizio? Certo che posso documentarlo, ma voglio forzarli.

Nota: non posso chiamare il release()metodo nel doWork()metodo, perché ho doWork() bisogno di quegli oggetti quando viene chiamato in seguito.

La soluzione pragmatica è quella di creare la classe AutoCloseablee fornire un finalize()metodo come backstop (se appropriato ... vedi sotto!). Quindi fai affidamento sugli utenti della tua classe per utilizzare try-with-resource o chiamare close()esplicitamente.

Certo che posso documentarlo, ma voglio forzarli.

Sfortunatamente, non c'è modo ¹ in Java di forzare il programmatore a fare la cosa giusta. Il meglio che potresti sperare di fare è raccogliere un utilizzo errato in un analizzatore di codice statico.

Sul tema dei finalizzatori. Questa funzionalità Java ha pochissimi casi d'uso validi . Se fai affidamento sui finalizzatori per riordinare, ti imbatti nel problema che può richiedere molto tempo prima che il riordino abbia luogo. Il finalizzatore verrà eseguito solo dopo che il GC ha deciso che l'oggetto non è più raggiungibile. Ciò potrebbe non accadere fino a quando la JVM non eseguirà una raccolta completa .

Pertanto, se il problema che stai cercando di risolvere è recuperare risorse che devono essere rilasciate in anticipo , allora hai perso la barca usando la finalizzazione.

E nel caso in cui non abbiate ottenuto quello che sto dicendo sopra ... non è quasi mai appropriato usare i finalizzatori nel codice di produzione e non dovreste mai fare affidamento su di essi!

^{1 - Ci sono modi. Se si è pronti a "nascondere" gli oggetti di servizio dal codice utente o controllare strettamente il loro ciclo di vita (ad es. Https://softwareengineering.stackexchange.com/a/345100/172 ), non è necessario chiamare il codice degli utenti release(). Tuttavia, l'API diventa più complicata, limitata ... e "brutta" IMO. Inoltre, ciò non obbliga il programmatore a fare la cosa giusta . Rimuove la capacità del programmatore di fare la cosa sbagliata!}

Questo sembra il caso d'uso per l' AutoCloseableinterfaccia e l' try-with-resourcesistruzione introdotta in Java 7. Se hai qualcosa di simile

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

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

quindi i tuoi consumatori possono usarlo come

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

e non devi preoccuparti di chiamare un esplicito releaseindipendentemente dal fatto che il loro codice generi un'eccezione.

Risposta aggiuntiva

Se quello che stai veramente cercando è assicurarti che nessuno possa dimenticare di usare la tua funzione, devi fare un paio di cose

1. Assicurarsi che tutti i costruttori di MyServicesiano privati.
2. Definire un singolo punto di accesso da utilizzare per MyServicegarantire che venga ripulito dopo.

Faresti qualcosa del genere

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

Lo useresti quindi come

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

All'inizio non ho raccomandato questo percorso perché è orribile senza lambda Java-8 e interfacce funzionali (dove MyServiceConsumerdiventa Consumer<MyService>) ed è abbastanza imponente per i tuoi consumatori. Ma se quello che vuoi solo è che release()deve essere chiamato, funzionerà.

si, puoi

Puoi assolutamente costringerli a rilasciarlo e renderlo impossibile da dimenticare al 100%, rendendo impossibile per loro creare nuove Serviceistanze.

Se hanno fatto qualcosa del genere prima:

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

Quindi modificalo in modo che debbano accedervi in ​​questo modo.

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

Avvertenze:

• Considera questo pseudocodice, sono passati secoli da quando ho scritto Java.
• In questi giorni potrebbero esserci varianti più eleganti, forse includendo quell'interfaccia AutoCloseablemenzionata da qualcuno; ma l'esempio dato dovrebbe funzionare fuori dagli schemi, e fatta eccezione per l'eleganza (che è un bel obiettivo in sé) non ci dovrebbero essere ragioni importanti per cambiarlo. Si noti che ciò intende dire che è possibile utilizzare AutoCloseableall'interno dell'implementazione privata; il vantaggio della mia soluzione rispetto all'utilizzo dei tuoi utenti AutoCloseableè che non può essere nuovamente dimenticato.
• Dovrai perfezionarlo secondo necessità, ad esempio per inserire argomenti nella new Servicechiamata.
• Come menzionato nei commenti, la questione se un costrutto come questo (ovvero, prendere il processo di creazione e distruzione di a Service) appartenga o meno alla mano del chiamante non rientra nell'ambito di questa risposta. Ma se decidi di averne assolutamente bisogno, ecco come puoi farlo.
• Un commentatore ha fornito queste informazioni sulla gestione delle eccezioni: Google Libri

Potresti provare a utilizzare il modello di 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();
    }

}

Questo ti dà il pieno controllo sull'acquisizione e il rilascio delle risorse. Il chiamante invia solo attività al tuo Servizio e tu stesso sei responsabile dell'acquisizione e della pulizia delle risorse.

C'è un problema, tuttavia. Il chiamante può ancora fare questo:

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

Ma puoi risolvere questo problema quando si presenta. Quando ci sono problemi di prestazioni e scopri che alcuni chiamanti lo fanno, mostra loro il modo corretto e risolvi il problema:

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

Puoi renderlo arbitrariamente complesso implementando promesse per attività che dipendono da altre attività, ma poi rilasciare cose diventa anche più complicato. Questo è solo un punto di partenza.

Async

Come è stato sottolineato nei commenti, quanto sopra non funziona davvero con richieste asincrone. È corretto. Ma questo può essere facilmente risolto in Java 8 con l'uso di CompleteableFuture , in particolare CompleteableFuture#supplyAsyncper creare i singoli futuri e CompleteableFuture#allOfperfezionare il rilascio delle risorse al termine di tutte le attività. In alternativa, è sempre possibile utilizzare Thread o ExecutorServices per implementare la propria implementazione di Futures / Promesse.

Se possibile, non consentire all'utente di creare la risorsa. Consenti all'utente di passare un oggetto visitatore al tuo metodo, che creerà la risorsa, passerà al metodo dell'oggetto visitatore e rilascerà successivamente.

La mia idea era simile a quella di Polygnome.

Puoi avere i metodi "do_something ()" nella tua classe semplicemente aggiungendo comandi a un elenco di comandi privato. Quindi, disporre di un metodo "commit ()" che effettivamente fa il lavoro e chiama "release ()".

Quindi, se l'utente non chiama mai commit (), il lavoro non viene mai eseguito. In tal caso, le risorse vengono liberate.

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

}

Puoi quindi usarlo come foo.doSomething.doSomethineElse (). Commit ();

Un'altra alternativa a quelle menzionate sarebbe l'uso di "riferimenti intelligenti" per gestire le risorse incapsulate in un modo che consenta al garbage collector di ripulire automaticamente senza liberare manualmente le risorse. La loro utilità dipende ovviamente dalla vostra implementazione. Maggiori informazioni su questo argomento in questo meraviglioso post sul blog: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

Per qualsiasi altro linguaggio orientato alla classe direi di metterlo nel distruttore, ma dal momento che questa non è un'opzione penso che tu possa scavalcare il metodo finalize. In questo modo, quando l'istanza non rientra nell'ambito di applicazione e viene raccolta spazzatura, verrà rilasciata.

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

Non ho molta familiarità con Java, ma penso che questo sia lo scopo per cui è finalizzato ().

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