Concurrency, reflection and Factory pattern

[Maciej]

Hi everyone,

Here is my problem:

Case:
- server application which launches concurrently tasks (precisely
classes extending class Task)
- new types of task can be registered at the server by the developer
- only class of task which matches incoming request, is launched

Proposed solution:
- Developer registers not instances of tasks, but their classes in the
server
- If static method matches() of one task's class returns true, then
this class is instancianized by use of Java reflection

Pros:
1. no instance of Task class is necessary to check its matching
condition
2. both: matching condition and related solve() method are defined in a
single class

Cons:
1. this approach is easy to abuse, since static methods cannot be
abstract and or overriden, which does not force developer to implement
them in classes which derive from Task class.

I was wondering about using Factory pattern, which creates instances of
class, but this forces me to break 2nd advantage. Do you see any other
solution ?

TIA,
Maciej

ps. Here is example of Task class

public abstract class Task<R,T> {

private R request;

/* This method must be implemented in deriving class */
public abstract T solve();

/* This method method must be over-hidden in deriving class. */
public static boolean matches(R request) {
return false;
}

public Task(R request) {
this.request = request;
}

 

[Thomas Hawtin]

Case:
- server application which launches concurrently tasks (precisely
classes extending class Task)
- new types of task can be registered at the server by the developer
- only class of task which matches incoming request, is launched

Proposed solution:
- Developer registers not instances of tasks, but their classes in the
server
- If static method matches() of one task's class returns true, then
this class is instancianized by use of Java reflection

Pros:
1. no instance of Task class is necessary to check its matching
condition
2. both: matching condition and related solve() method are defined in a
single class

Cons:
1. this approach is easy to abuse, since static methods cannot be
abstract and or overriden, which does not force developer to implement
them in classes which derive from Task class.

I was wondering about using Factory pattern, which creates instances of
class, but this forces me to break 2nd advantage. Do you see any other
solution ?

I don't think having two methods defined in the same class is a
particularly great advantage. Don't be afraid to create classes.

Is there any particular reason why you need to create a new instance to
call solve? Why not just make both matches and solve instance methods of
the same type? If there is a reason for separate types, abstract factory
is far and away better than messing with reflection.

Tom Hawtin

 

[Maciej]

Is there any particular reason why you need to create a new instance to

call solve?

Concurrent launching of the same type of Task -- that's the reason.

Why not just make both matches and solve instance methods of

the same type? If there is a reason for separate types, abstract factory
is far and away better than messing with reflection.

Factory seems good solution. But itrequires re-editing factory each
time new type of Task is developed (to add matching filter). In my
approach this can be done by editing only Task class.

Maciej