Re: Concurrency, reflection and Factory pattern

From:

Thomas Hawtin <usenet@tackline.plus.com>

Newsgroups:

comp.lang.java.programmer

Date:

Thu, 30 Nov 2006 14:53:09 +0000

Message-ID:

<456ef01d$0$8723$ed2619ec@ptn-nntp-reader02.plus.net>

Maciej wrote:

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