How to abstract over DelegateTask and Task

What’s the conceptual difference between these classes?

  • org.camunda.bpm.engine.delegate.DelegateTask
  • org.camunda.bpm.engine.task.Task

I am abstracting over them - because I do stuff with tasks and sometimes the tasks come from an event and sometimes from the task service - but they don’t share a supertype even though they share a large number of getters and setters. Is there any particular reason that they don’t?

Conceptually, I think they’re very similar. Delegation allows you entrust work (all or part) to another party (more on the lifecycle here).

It’s hard not to feel like we’re about to cross wires a bit because I don’t have too much info on what you’re trying to accomplish, but I can give it a shot (frankly you may only get a great answer from the OG developers :slight_smile:) … DelegateTask and Task are interfaces. As far as the engine platform goes, the only implementer is at the persistence layer, org.camunda.bpm.engine.impl.persistence.entity.TaskEntity.

Taking that class into consideration, but also considering Java’s lack of multi-inheritance support, I think trying to subclass all the “task things” may have created a bit of a mess. With the interfaces as defined, along with some overlap in methods, the code is pretty clean as written. This way, you can implement the interfaces you need in your classes as needed.

Having said all that, the answer to the true spirit of your question likely lies in history somewhere. Maybe once upon a time DelegateTask couldn’t extend Task. Taking a quick glance at it in current state, nothing jumped out at me as preventing such a refactor.

As far as I understand, the ‘Delegate’ part of ‘DelegateTask’ has nothing to do with task delegation, but is similar to the ‘Delegate’ in ‘JavaDelegate’.

That even means that the class ‘DelegateTask’ and the method ‘delegateTask’ on ‘Task’ are essentially unrelated, and both referring to a different ‘delegate’ idea.

Historic reasons make sense here indeed :slight_smile: