Tim,
I like where you're going with this. Having opt-in interface
inheritance rather than opt-out implementation extension seems a lot
more flexible and a lot lighter weight. Framework helpers, such as
content negotiation, could be injected as (mockable--hah! back to
testing) collaborators using "has a" rather than "is a" relationships.
Justin
On Nov 29, 2007, at 8:37 AM, Tim Peierls wrote:
On Nov 29, 2007 10:57 AM, Rob Heittman <[EMAIL PROTECTED]>
wrote:
Hmmm. I feel myself spiraling back to the interfaces vs classes
question.
Don't go into the light! :-) Isn't this just more evidence that
it's very hard to specify interfaces in unstable APIs?
But now you've got me thinking. What if (some day) there were a
suite of small interfaces like this:
interface AcceptsRepresentations<T> {
AcceptResult accept(Representation<T> rep);
}
and resource (lower-case 'r') classes just implemented these
interfaces, e.g.,
class MyResource
extends AbstractResource
implements AcceptsRepresentations<SomeRep>,
GetsRepresentations, RemovesRepresentations {
public AcceptResult accept(Representation<SomeRep> rep) { ... }
// get/variants, remove, etc.
...
}
That would finesse the whole exception issue, since the
AcceptResult (and other XXXResult types) would carry the
information that an exception would.
Other than imposing a consistent method naming scheme
(checkedStoreRepresentation is the checked version of
storeRepresentation ...) your proposal would work for me. I would
want the ability to do a fairly simple regex operation across my
code in the future to remove the extra level of wrapping.
These names should typically only appear in method declarations of
CheckedResource subclasses, so it should be easy to change them.
And wouldn't you prefer shorter, less redundant names, e.g .,
accepts(Representation) instead of acceptsRepresentation
(Representation)?
--tim
