robotlegs/robotlegs-framework — Issue #62: Mediator Matching
Author: darscan
Created: 2012-01-26 22:10:59+00:00
State: open

There are two options for mediator view matching:

1. Any hamcrest matcher you like.
2. Specialized/restricted Robotlegs matcher.

# Option 1 (Arbitrary Object Matching)

Allows a great deal of flexibility, but there are concerns that if offers too much in the way of "rope".

## Pros

1. Flexible - any matcher you can think up.
2. Work done - a full suite of tested matchers already exist in the Hamcrest library.
3. Consistent - other parts of the Robotlegs API use the Hamcrest API for matching.
4. Feature parity with Option 2 - the TypeMatcher used as a restriction in Option 2 can still be used with this approach.

## Cons

1. Perhaps too flexible - concerns that developers may do silly things.
2. Harder to tool - arbitrary matchers might not provide enough information to help the mediator factory decide what types to map the view instance to, for example.

# Option 2 (Specialized Type Matching)

Restricts usage by employing a custom matcher interface tailored for "type matching". This reduces the "rope" factor, but is less flexible.

## Pros

1. Prevents developer mistakes.
2. Can be optimised for internal use by the mediator factory.

## Cons

1. At odds with the rest of the RL2 API.
2. Less flexible.

# Your thoughts?

Personally I'm keen for Option 1 - even if purely to keep the RL2 API consistent.

Which option are you in favour of?