Sam Ruby: "What I described in Coping with Change is not related to late binding or IDispatch. It is all about things - even early bound things - continuing to work after change."
Alas, communication is a difficult thing. The reference to IDispatch was metaphorical. What you talk about is an approach that very much resembles the scripting and IDispatch way of doing things. Think metaphorical, not literal.
Several points from your doc:
"If you have a protocol which is designed to support named parameter associations, adding a new parameter is easy. One merely requires the recipient to match the actual parameters to the arguments that they were expecting, to ignore anything they do not understand, and provide reasonable defaults for anything that they were expecting that they do not receive. "
and
"Once you accept that interfaces may change over time, you will soon see the need for some level of metadata in order to aid discovery. XML schema can be embedded in the message to make the content self defining. Or it can be contained in a separate document (e.g.., WSDL). "
and
"As a general rule, the more metadata the better."
The point that sticks out here is: Your technique works without runtime metadata (early binding), but it works best if there is runtime metadata (late binding). Who cares if the metadata is included in the SOAP message, a WSDL document, or anywhere else. Your talking about a programming style. I'm talking about a design style. Two different things. I say again: we're looking at this from two different points of view. They are not mutually exclusive to one another.
The original discussion is about how to best treat WSDL interface descriptions through multiple iterations. The technique I describe in Patterns of Change 1 & 2 is one method of achieving exactly the type of thing you are talking about in Coping with Change using a strongly typed WSDL interface description that is capable of being extended dynamically without changing the underlying interface.
Go back and look at the example. New operations and new parameters (or modified operations and modified parameters) can be added to the service ad infinitum without ever having to change the WSDL interface. The requester and provider can then choose to support whichever combination operations and parameters they wish. If the client sends a request to the server that the server doesn't support, the server can either throw an error or ignore it. If the server responds with data that the client doesn't understand, the client can throw an error or ignore it. The point is, the interface description supports type safe evolution by design.
To explain the IDispatch metaphor a bit more, let's look at how your scenario would be realized in pre VB.net code:
Two ways in the old VB to allow extensible parameters (e.g. the ability to add a title parameter)
- Sub PostItem(String body, Optional String title)
- Sub PostItem(ParamArray options() as Variant)
The first allows for named parameters, the second allows for unnamed parameters. A COM scripting client doesn't really care which is used. Because it uses IDispatch under the covers, it is provided the necessary metadata at runtime (metaphorical equivalent to loading the WSDL or putting a schema in the request/response) it can cope with the change. Early bound clients can support this as well, but it takes more work.
The approach I suggest, however, looks something like (switching to Java now)
- public CommandResponse doCommand(CommandRequest command)
CommandRequest is completely flexible. Not only can the server/client support/ignore/reject new parameters, but entirely new operations, and multiple even versions of operations. We achieve the result you describe while still promoting good interface design.
Anyway, that's it, I'm getting ready to go on vacation now.
9:39:23 AM 
|
