RE: Admissible Evidence

(Possible final comment on this from me for a few hours, as it's getting
late.)

 

Again with thanks to Jo for prompting this thought, there is yet another
approach. The implementation-side interface for an instance of evidence
is not visible in the Simple API because it is implementation specific.
Yet it is important that the retrieval contract is established when
passing such an instance as a parameter. How can this contract be
guaranteed by the Simple API?

 

There is a way. Each implementation of the SimpleService class could
also provide a factory that creates evidence objects. The factory can
thus ensure that whatever is produced will adhere to the retrieval
contract. The external developer merely obtains a blank evidence object
via the factory and populates it with evidentiary information. (Or this
raw info could be given as data to the factory method.)

 

The object produced by the factory should still adhere to a visible
external contract for populating it with data. We could call this
interface "Evidence" and it should have a put method. (The object could
also implement additional population methods but those would be on a
per-implementation basis. Always room for a bit of improvement.)

 

Now, on the way back in, as a parameter in a getPropertyValue method,
this same evidence object would also have to implement the back-end
retrieval contract. We don't have to provide any details about what is
in this contract. For me, I'm happy to look at this hidden retrieval
contract as the one called Admissible. This interface doesn't even have
to be mentioned in the Simple API definition. It's only known to the
implementation of the factory and the query methods. The external
developer doesn't need to know about it.

 

So we may have a solution to this issue if we use a factory method in
the SimpleService to create evidence objects.

 

And now I'm disconnecting...

 

---Rotan.

Received on Monday, 25 February 2008 23:29:48 UTC