What do you really need in the common interface? Mapping positions and parameter names to value objects?
How about ITuple?
>I find option B much more appropriate.
I agree, but I also share the other István's concern about ripple effects.
An initial & superficial & quick & dirty change impact analysis:
- ITuple and BaseTuple should extract parameterNames(), getters, setters, isMutable(), toArray(), prettyPrint(), isCompatibleWith() and most importantly the semantics.
- ITuple needs a "schema", which is the pattern in case of IPatternMatch, and ComplexEventDefinition or whatever in your case. This is schema required, at the very least, for comparison in equals(). The type-safe alias pattern() should remain in IPatternMatch.
- ITupleProcessor superinterface for IMatchProcessor... or maybe eliminate IMatchProcessor altogether.
- an EVM Job should accept an ITuple, and the context-free/stateless version should be constructible for an ITupleProcessor of the right tuple type
- Activation should associate with an ITuple
- and the most difficult part: associating RuleSpecifications with something (~MatcherFactory) that will be able to hook onto an Engine to create an event source (~Matcher) that will eventually provide events characterized by ITuples of the right type.
For the last part, I think Ábel may provide more insight.
Cheers,
