> >>> * define task contexts that define various common aspects
> >>> * (logging, failure handling ...) and assign them to tasks.
> >>
> >>Need more input - on the "and assign" part.
> >
> > I was thinking something as simple as the following for logging.
> >
> > interface Task
> > {
> > void setTaskContext( TaskContext context );
> > {
> >
> > class MyTask
> > {
> > TaskContext context;
> >
> > void setTaskContext( TaskContext context )
> > {
> > this.context = context;
> > }
> >
> > Logger getLogger()
> > {
> > return context.getLogger();
> > }
>
> [...]
>
> wouldn't setTaskContext and getLogger better by part of an abstract
> Task (and why should Task be an interface)? But we are getting into
> details here.
IMO no.
>why should Task be an interface?
Basically it is not necessary for task to be an abstract/conrete class. Because
it can be
implemented as an interface. Some situations require that a you use an abstract
class or
concrete class so if other things you wish to extend/implement are all
interfaces it is cleaner
otherwise you end up using adapters everywhere and it gets ugly.
Michael
