<th*********@gmail.com> wrote in message
news:11*********************@i40g2000cwc.googlegro ups.com...
Thanks,
I guess we dont' exactly use the same lingo...
Lets define a term "transformation" (what I want)
The "transformation" is the act of calling:
implicit or explicit numeric conversions
implicit or explicit User-defined conversions.
Fair enough, Transformation works fine
This does not cover base class generalistaion (non-user-defined cast to
a parent type or to an implemented interface). The reason being that
the object is already of that type and hence our function would be of
no benifit. Notice that in my example dog did not derive from
carnivourusAnimal. If dog had derived from carnivourusAnimal then there
would be no poing in doing the cast sice the dog would already be a
carnivourusAnimal.
I believe that this was the source of some confusion in some of the responses.
when the doCast function is called a serach is conducted for a suitable
"transformation" and that transformation is applied.
This is probably most usefull in situations where a comunications class
species a type which it expects to recive information in.
Basicly what I want is a way for objects "product" to be shaped into a
type that may be required by another process "consumer". The process
does not need to be altered to accomidate new classes that apear. The
process needs only to provide information on what type it requires.
The "item" class then only needs a suitable user-defined conversion and
its intergration into the application is done.
OK, I am confused again.
Is an "item" class different from a "product" class, or have we changed names????
This is only usefull if new "item" classss are often indroduced into
the aplication and the what the "consumer" wants is determined at
runtime, and what the consumer expects can not be generalised to a base
class or common interface.
OK,
I think the problem most of us are having is that you are asking for a general object to object
transform method/class. However, in general, most objects SHOULD NOT be convertible into any old
object. Don't get me wrong, You COULD write a general object transformer, but most of the cases
would need to throw some "Untransformable" Exception. And in general, the results would not be
pretty.
Of cause looking at your product/item/consumer description, it doesn't look like you really need
a generic transformer at all. So the real question is, "What do you really need?"
So let me ask a few questions, to narrow down the scope a bit.
Are we talking about external vendors? Web services? In house services? Are they separate processes
or just separate threads?
How many consumers are we talking about? Do they do the same thing, or different things?
Will CONSUMER_A always want the same type, or will it vary from call to call?
Is each product a different class?
Is there a common ancestor?
Is there a 1- to -1 mapping of objects from your side to the "consumer" side?
ProductA -->Consumer1ProductA
ProductA -->Consumer2ProductA
ProductB -->Consumer1ProductB
ProductB -->Consumer2ProductB
Or is more like this
ProductA -->Consumer1Product
ProductA -->Consumer2Product
ProductB -->Consumer1Product
ProductB -->Consumer2Product
Or is it something more complex?
I guess the bottom line is that depending on the problem you are attempting to solve, the best
solution may look quite different. However, I am fairly certain that a generic "Transformer" is
probably not the ideal solution. I am not saying that you don't need a means of converting types, I
am simply saying that it would be better to narrow down the scope to something smaller that
"anything to anything else".
Bill