Originally posted by Frank Carver:
Hmm. You could always make it an Object, and cast it as needed. On the other hand if your returned messages have anything in common you could return an interface or base class. What sort of behaviour do these returned message wrappers have ? what wil you do with one when you get it back ?
Can we step back a little and ask what is the purpose of these "wrapper" classes ? It seems that they are causing a lot of head scratching, so maybe there is a simpler way of achieving the same ends. Can you list the benefits of using a "wrapper" class?
Originally posted by Frank Carver:
OK, how "tree-like" is the data contained in the wrapper classes? My guess is that it is just a set of name-value pairs. If so, have you considered abandoning the custom classes and just returning a Map? This provides the ability to get individual named entries and iterate through them to display them "for free".
Originally posted by John Ryan:
However i cant seem to figure a way that i can get one sendRequest method to be able to send all my requests and deliver responses. Will i need to have a sendRequest method for each pair of messages i have?
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Frank Carver:
Oh I agree it's a flexibility/complexity tradeoff. But in the particular situation described here, where someone wants to have a single data type to return from a "send" method, a Map nicely cuts through the crap.
I'm not saying that it has to be an unadorned HashMap or whatever, though.
I often subclass or decorate Maps to provide extra, specific, typed accessors, but leave the basic Map behaviour available. Then any client code may use the generic get/put/iterator interface if it doesn't need to know about specific types and accessors (such as when rendering all attributes to a form or table), and the specific ones if it knows about the domain classes and wants type-safe access to specific values.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Originally posted by Ilja Preuss:
I think here are two different forces at work:
First, you want to present your clients an as explicit API as possible - you want to abstract from the XML messages and String keys and they shouldn't need to cast anything. To accomplish this, it would possibly be a good idea to give every Request object a send method which returns the appropriate Response object.
?
Originally posted by Ilja Preuss:
OTOH, you want to avoid duplicated code. The send methods are probably very similar - you might even need only one if factored properly.
So what do we do to get the best of the two worlds? It's hard to say without working directly on the code, but here is a rough idea:
The Request objects could expose the aforementioned specific send methods to the clients, but internally delegate most of the work to a general send method. The Request objects then would do all the casting, so that the clients don't need to care about it.
How does that sound to you?
Originally posted by Frank Carver:
I'm even more puzzled then. Can you give me some examples of the "accessor methods" provded by your wrapper classes?
It seems to me you might have two possible types: Ones which return a specific value from somewhere in the returned message tree (e.g. String getDestinationAddress(), int getRowCount() ) and ones which return some complex type which requires further knowledge of what to do with it (e.g. AddressDetails getAddressDetails(), Iterator getMessageParts() ). In both these cases you actually have a simple name-value mapping (from the method name to the returned object) which could be represented in a Map.
Are you planning to use some other sort of "accessor" which I can't think of right now ?
Originally posted by Frank Carver:
Ilja wrote: I wonder wether the OP does *need* the generic behaviour.
That's one thing we haven't asked yet. What use is planned for the returned data. I may have been jumping to cvonclusions based on the similar thread I referred to, but often the end results are just iterated through and presented to the user. In this case, the use of custom classes and specific accessors just gets in the way.
Consider Paul's rocket mass heater. |