У бібліотеці Java 7 у мене є клас, який надає послуги іншим класам. Після створення екземпляра цього класу обслуговування один метод його може бути викликаний кілька разів (назвемо його doWork()методом). Тож я не знаю, коли робота класу обслуговування закінчена.

Проблема полягає в тому, що клас обслуговування використовує важкі об'єкти, і він повинен звільнити їх. Я встановив цю частину методом (назвемо так release()), але не гарантується, що інші розробники будуть використовувати цей метод.

Чи є спосіб змусити інших розробників викликати цей метод після виконання завдання сервісного класу? Звичайно, я можу це документувати, але хочу їх змусити.

Примітка: я не можу викликати release()метод у doWork()методі, тому що doWork() потрібні ці об'єкти, коли він викликається у наступному.

Прагматичне рішення - скласти клас AutoCloseableта надати finalize()метод як зворотний стоп (якщо це доречно ... див. Нижче!). Тоді ви покладаєтесь на користувачів вашого класу, щоб користуватися пробним ресурсом або close()явно телефонувати .

Звичайно, я можу це документувати, але хочу їх змусити.

На жаль, немає ніякого способу ¹ в Java , щоб змусити програміста зробити правильну річ. Найкраще, на що ви можете сподіватися, - це підібрати неправильне використання в аналізаторі статичного коду.

По темі фіналізаторів. Ця функція Java має дуже мало корисних випадків використання. Якщо ви покладаєтесь на фіналізатори, щоб привести в порядок, ви зіткнетесь з проблемою, що це може зайняти дуже багато часу, щоб привести в порядок. Фіналізатор буде запущений лише після того, як GC вирішить, що об'єкт більше недоступний. Це може не статися до тих пір, поки JVM не зробить повну колекцію.

Таким чином, якщо проблема, яку ви вирішуєте вирішити, це повернути ресурси, які потрібно звільнити достроково , то ви пропустили човен, використовуючи остаточну роботу.

І на всякий випадок, якщо у вас немає того, про що я говорив вище ... майже ніколи не доцільно використовувати фіналізатори у виробничому коді, і ви ніколи не повинні покладатися на них!

^{1 - Є способи. Якщо ви готові "заховати" об’єкти сервісу від коду користувача або жорстко контролювати їх життєвий цикл (наприклад, https://softwareengineering.stackexchange.com/a/345100/172 ), тоді користувачеві код не потрібно дзвонити release(). Однак API стає складнішим, обмеженим ... та "потворним" ІМО. Також це не змушує програміста робити правильно . Це усунення здатності програміста робити неправильну справу!}

Це здається випадком використання для AutoCloseableінтерфейсу та try-with-resourcesзаявою, представленою на Java 7. Якщо у вас є щось подібне

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

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

то ваші споживачі можуть використовувати його як

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

і не потрібно турбуватися про виклик явного, releaseнезалежно від того, чи є їх код винятком.

Додаткова відповідь

Якщо ви справді шукаєте - переконатися, що ніхто не може забути скористатися вашою функцією, вам доведеться зробити пару речей

1. Переконайтеся, що всі конструктори " MyServiceприватні".
2. Визначте єдиний пункт входу, який слід використовувати, MyServiceщо забезпечує його очищення після.

Ви б робили щось подібне

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

Потім ви використовуєте його як

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

Я не рекомендував цей шлях спочатку, оскільки він огидний без лямбдів Java-8 та функціональних інтерфейсів (де це MyServiceConsumerстає Consumer<MyService>), і він досить нав'язує вашим споживачам. Але якщо ви хочете лише те, що release()потрібно викликати, це спрацює.

так, ти можеш

Ви можете абсолютно змусити їх звільнитись і зробити так, щоб забути на 100% неможливо, зробивши неможливим створення нових Serviceпримірників.

Якщо раніше вони робили щось подібне:

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

Потім змініть його, щоб вони мали доступ до нього так.

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

Застереження:

• Розглянемо цей псевдокод, він пройшов віки з тих пір, як я написав Java.
• Ці дні можуть бути більш елегантні варіанти, можливо, включаючи той AutoCloseableінтерфейс, який хтось згадав; але наведений приклад повинен працювати нестандартно, і окрім елегантності (яка сама по собі приємна мета) не повинно бути жодної основної причини для її зміни. Зауважте, що це має намір сказати, що ви можете використовувати AutoCloseableвсередині вашої приватної реалізації; користь мого рішення над тим, як користувачі користуються, AutoCloseableполягає в тому, що це, знову ж таки, не можна забути.
• Вам доведеться його чітко розробити, наприклад, ввести аргументи у new Serviceвиклик.
• Як зазначалося в коментарях, питання про те, чи належить така конструкція (тобто, взявши процес створення та знищення а Service), належить до руки абонента чи ні, не виходить за рамки цієї відповіді. Але якщо ви вирішили, що вам це абсолютно потрібно, саме так ви можете це зробити.
• Один із коментаторів надав цю інформацію щодо обробки винятків: Google Books

Ви можете спробувати скористатися шаблоном Command .

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

}

Це дає вам повний контроль над придбанням та випуском ресурсів. Абонент подає завдання лише Вашій Службі, а ви самі несете відповідальність за придбання та очищення ресурсів.

Однак є улов. Абонент може все-таки зробити це:

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

Але ви можете вирішити цю проблему, коли вона виникає. Коли виникають проблеми з продуктивністю, і ви дізнаєтесь, що хтось, хто телефонує, робить це, просто покажіть їм належний спосіб і вирішіть проблему:

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

Ви можете зробити це довільно складним шляхом, виконуючи обіцянки для завдань, які залежать від інших завдань, але потім вивільнення матеріалів також ускладнюється. Це лише вихідний пункт.

Асинхронізація

Як було зазначено в коментарях, вищезазначене насправді не працює з асинхронними запитами. Це правильно. Але це може бути легко вирішено в Java 8 із застосуванням CompleteableFuture , особливо CompleteableFuture#supplyAsyncдля створення індивідуальних ф'ючерсів та CompleteableFuture#allOfдля досконалого випуску ресурсів, коли всі завдання завершені. Крім того, завжди можна використовувати теми або сервіси ExecutorServices, щоб виконати власну реалізацію Futures / Promises.

Якщо можете, не дозволяйте користувачеві створювати ресурс. Дозвольте користувачеві передати об’єкт відвідувача вашому методу, який створить ресурс, передати його методу об’єкта відвідувача і після цього звільнити.

Моя ідея була схожа на Полігномову.

Ви можете мати методи "do_something ()" у своєму класі просто додавати команди до приватного списку команд. Потім укажіть метод "commit ()", який фактично виконує роботу, і викликає "release ()".

Таким чином, якщо користувач ніколи не викликає commit (), робота ніколи не виконується. Якщо вони це роблять, ресурси звільняються.

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

}

Потім ви можете використовувати його як foo.doSomething.doSomethineElse (). Commit ();

Ще однією альтернативою згаданим було б використання "розумних посилань" для управління вашими інкапсульованими ресурсами таким чином, що дозволяє сміттєзбірнику автоматично очищатись без ручного звільнення ресурсів. Їх корисність залежить, звичайно, від вашої реалізації. Детальніше про цю тему читайте в цій чудовій публікації в блозі: https://community.oracle.com/blogs/enicholas/2006/05/04/understanding-weak-references

Для будь-якої іншої мови, орієнтованої на клас, я б сказав, що я поставив його в деструктор, але оскільки це не варіант, я думаю, що ви можете перекрити метод завершення. Таким чином, коли екземпляр вийде за межі і буде зібрано сміття, він буде випущений.

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

Я не надто знайомий з Java, але вважаю, що саме ця мета призначена для finalize ().

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