-1

I am looking for a good name of an interface having a run method like Runnable but returning a result.

Options I currently consider are:

  1. Calculation -> too mathematically, and not everything returning a result is a calculation

  2. Function -> Quite near to what I am looking but it is still too mathematically

  3. Action -> Is a missfit due it does not necessary produce a result

  4. Operation -> That would be my current favorite but mathematically it might only describe a relationship without producing a result being more liek a condition. Same as action

  5. Provider -> Provider means to give something to someone/something, that is not always the case as returning a result of such a runnable is quite common

  6. Supplier -> See Provider

  7. Task -> Is something worth considering but would interfere with another notation of a task being something that is executed by a scheduler.

  8. Work -> Might work but work as in Work-flow is better saved like Task.

  9. Job -> Same as with task

  10. Process -> Might work but again is better be reserved as well as not all results are produced by an actually process (getter example)

These are the alternatives I have found. The closest bet is a Supplier or ResultSupplier interface but it sounds awkward.

Does anyone have a better naming idea or knows frameworks that live happily with the presented (or currently missed out) alternatives?

Martin Kersten
  • 5,127
  • 8
  • 46
  • 77
  • If you can't find a proper name, something is probably wrong in your design. – Tunaki Aug 27 '15 at 18:41
  • 1
    There are only two hard things in Computer Science: cache invalidation and naming things. -- Phil Karlton. I like the OPs effort to find a proper name. – wero Aug 27 '15 at 18:48
  • Although the explicit question is opinion-based, this may be an XY problem with an underlying X that is not. Such an interface already exists, and already has a name. – Andy Thomas Aug 27 '15 at 19:10
  • I need to reimplement those interfaces to support variable arguments and being expressable by lambda expressions (http://stackoverflow.com/questions/32209621/java-8-lamda-lambda-with-variable-arguments). So I want to find good enough names without adding confusion by reusing certain names like producer throughout the platform / framework. – Martin Kersten Aug 27 '15 at 21:24

3 Answers3

6

How about the existing interface java.util.concurrent.Callable<V> ?

public interface Callable<V> {
  /**
   * Computes a result, or throws an exception if unable to do so.
   *
   * @return computed result
   * @throws Exception if unable to compute a result
   */
  V call() throws Exception;
}
Andy Thomas
  • 84,978
  • 11
  • 107
  • 151
  • Java 8's `Supplier` is probably what the OP wants - it doesn't have the `throws Exception`, which isn't mentioned. – bcsb1001 Aug 27 '15 at 18:46
  • If your speculation is correct, the OP could also extend Callable with an interface that overrode `call()` with no `throws`. `Callable.call()` suggests something that can be called that might or might not have some side effects, and returns a result. `Supplier.get()` suggests something whose primary purpose is to return a result. – Andy Thomas Aug 27 '15 at 18:55
  • A supplier is providing something that usually is suggested to be already present. Callable is nothing that hits the nail on the head but runnable is also quite broad so I guess I will go this route and want to preserve the precious names like Producer or Supplier or even Operation / Function. – Martin Kersten Aug 27 '15 at 20:27
4

How about Callable which is built into the JVM and calls the method call()

So Callable<V> returns the type V it also can throw Exceptions

It is used by the ExecutorService interface to manage multithreaded processing.

Here is a link to Oracle's ExecutorService tutorial

dkatzel
  • 31,188
  • 3
  • 63
  • 67
  • Doesn't had that one on the radar. I guess I will go with callable since it is quite old, accepted and it can be distinguished from runnable. Producer is closer to what it is but in the end Producer is something that I want to preserve for the Producer + Consumer Pattern which gets also implemented when it comes to the Event handling. SO thanks alot for the suggestion. – Martin Kersten Aug 27 '15 at 20:26
0

What do you think about Producer<T>?

wero
  • 32,544
  • 3
  • 59
  • 84