Re: design question about "programming to interfaces"

Chris Brat wrote:


That could work if the arguments are simple data, e.g. string etc.. But
if I used objects I would still have to cast the objects to their
correct data type before using them. I don't have to declare the object
type in the Map<X,Y> definition, but that leads to handling by using a
super object/marker interface, which leads me back to where I started...

 > This is how the HttpServletRequest object deals with parameters
 > supplied in the request.

I suspect the reason it is done in that way in HttpServletRequest is
that it does not know in advance the potential parameters being
transferred. In contrast, when you design the system, you do know in
advance. Even though there might be different parameters at different
times/situations you would know in which situations the different
parameters are being used. I think that's a valid argument for the
httpservletrequest case, but I don't know if that is the reason or if
its the hole reason.

What about this idea.

I create a DTO object that can store any object type (for example in a
hash) but which contains a number for get/set methods for retrieving the
data in the correct data type. This would allow me to declare a single
data type for the data being passed, and I would only add a new get
method for new data types. It would add another level of indirection
which would complicate the code a bit, but it would make the code easier
to extend.

But this open up a question, how to iterate over the list of data? If I
do the usual, return an iterable from the underlying list, I would break
the intended encapsulation. Is it possible to create an iterable type
suitable for each return type? That would mean I would, in addition to
the get/setters for each data type, have to add f.ex. getNewsIterable()
etc.. I would also have to add code to support iteration of that type.
Now things are starting to get quite complex, and perhaps not worth the
effort, maybe its just easier to just duplicate the code? I know it
would lead to code maintenance/correctness problems, but it seems to be
the simpler method. I always prefer to keep it as simple as possible.

Are there any other possibilities?

In any case, this leads me to an observation I just made. It seems to me
that a lot of the work in programming java is dealing with indirection
code to solve how to dynamically pass/invoke different object types.
Would it not be easier if java did not have types, in the same way as
f.ex. python, ruby(?), lisp. Then, my original question would not apply.
My reason is as follows. When I program I know what data/object types
apply in the different cases, so I don't need the system to check that
for me. Hence all the indirection code to fool the system into passing
the data/objects I snot needed. I know there is the question of what
about when I make a mistake and pass the wrong object to a method, and
that java can check for such errors before hand. But it still makes for
an interesting idea, albeit, maybe a bit heretic in this news group :)

tom