design question about "programming to interfaces"

[Tom Forsmo]

I have a design problem that I am unsure of how to deal with, the
problem is as follows.

The basics:

I am creating a search dao for using google, the dao should support
several search types: pages, news, images and perhaps more. These
queries are similar in the mechanics as leveraged by the interfaces, but
the details are different, specifically the handling and passing of the
arguments and the result data throught the interfaces. Specifically, how
to specify the query string is the same for all, but the contents are
different because of the nature of each searchtype. The same goes for
the result. So, the question is how do I pass differing query arguments
and result data in a design based on "programming to interfaces".

The details:

Example: In addition to a common query string such as "car", "engine"
etc I can specify, for images: gif, jpg etc. colour/bw,
thumbnail/original etc. for the newsgroup, sender, threaded etc.
All of these special query parameters have their own parameter names.
The same goes for the result, the basic format is the same xml, but much
of the elements and attributes are specialised.

The mechanics of the search are the same; some parameterized query
arguments, the correct search engine and a mathcing result parser. All
which can be handled by interfaces and delegation.

The design problem I am having is how to deal with the query parameters
and the result data when programming to interfaces. I have allways been
told that one should expose the data in objects. Meaning, data to be
passed in an object should be given a member variable for each data
element with a corresponding get/set method. If I were to do that for
the search parameters and the resultlist I would need a new interface,
and implementation, for each new type of search I was doing. This would
result in massive dupliction of code. I could potentially create a super
object, or a marker interface, and use that as the datatype for the
search argument and resultlist type, but then I would have to insert
lots of casting and that would defeat the purpose of interfaces.

Any thoughts on how to do this properly?

regards

tom

 

[Chris Brat]

Hi

I'd pass the parameters through to the method as entries in a a
Map<String,String[]>
where the search key is the map key and the parameter values are
objects in the String[].

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

Chris

 

[Tom Forsmo]

Hi

I'd pass the parameters through to the method as entries in a a
Map<String,String[]>
where the search key is the map key and the parameter values are
objects in the String[].

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

> 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

 

[Lew]

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

Yes, it would not be easier. You could use Map <Object, Object[]> or
Map < ? extends Object, Object []> with appropriate casts with equal ease.

Removing types from Java, quite aside from making the language not be Java,
would complicate all sorts of other things that types and type-safety make
possible, much less easier. Types exist for a reason (many reasons), not just
to make your one "original question" harder for you to solve.

Your representation of the object-oriented type system as existing to "fool
the system" bespeaks a fundamental lack of understanding about types. Just to
mention one purpose, types properly used usually permit the compiler to catch
and prevent errors at compile time before they become bugs at run time.

If you prefer typeless programming, there are alternatives to Java. It
doesn't make sense to suggest undoing the most fundamental aspect of the
language, not because it's heretical but because it is fundamentally off.
It's like suggesting that carrots would be better if they were made of aluminium.

- Lew

 

[Tom Forsmo]

Removing types from Java, quite aside from making the language not be
Java, would complicate all sorts of other things that types and
type-safety make possible, much less easier. Types exist for a reason
(many reasons), not just to make your one "original question" harder for
you to solve.

Your representation of the object-oriented type system as existing to
"fool the system" bespeaks a fundamental lack of understanding about
types. Just to mention one purpose, types properly used usually permit
the compiler to catch and prevent errors at compile time before they
become bugs at run time.

Could you explaining in more detail all the things that would complicate
it, because the one example you gave as an oppositional argument I seem
to have mentioned in my previous post. Also, any explanations of my
apparent lack of understanding of types would be nice. Basically, any
constructive information that would cast more light on the matter would
be infinitely more appreciated.

If you prefer typeless programming, there are alternatives to Java.

That was not really the point. Its more a matter of an observation I
made about what I see as the complexities of programming with types,
coincidentally in the language I am programming in, java. So by airing
the thoughts I hoped to get constructive feedback with insights to the
complexity of the problem and specifically how that can help me solve
design and programming problems in the future.

tom

 

[Doug Pardee]

From what I was able to figure out from your description, it sounds
like you want to use shared behavior on different data types. For that
you would use genericity.

[Followup-to set to c.l.j.help only.]

 

[Lew]

Could you explaining in more detail all the things that would complicate
it, because the one example you gave as an oppositional argument I seem
to have mentioned in my previous post.

Consider an object in a typeless language like VBscript or Javascript, with
the pseudo-syntax:

v = "some string";
print v;

v = 143.5;
print v;

v = new { a="String element", b=16 };
print v.a, v.b;

Being untyped, v could be assigned an unexpected type occur at the wrong time
in a program, say in a function that has a bug,

v = "string when structure was still expected";

The caller might try to dereference v after the function,

print v.b;

and blow up. This can be very tricky to debug, since the reassignment could
have occurred in just about any part of the program. In a typed language, the
type mismatch occurs at compile time, before the program is deployed to
production and is therefore much easier to debug.

That's just one representative example.

Java was designed to be type-aware from the beginning; making it untyped would
make it not Java. Sure, there are times when untyped languages are more
convenient; that's why they exist. For large applications type-aware
languages are very helpful. That's part of why C++ has gained traction over
C, and why C# and Java are in their ascendancy.

- Lew

 

[Tom Forsmo]

Consider an object in a typeless language like VBscript or Javascript,
with the pseudo-syntax:

v = "some string";
v = 143.5;
v = new { a="String element", b=16 };

Being untyped, v could be assigned an unexpected type occur at the wrong
time in a program, say in a function that has a bug,
The caller might try to dereference v after the function,

Yes that is true, but only for an immature language.
In perl, for example there is a separation between scalar, arrays and
associative arrays. In Lisp, there are only lists as a type (there is
structs and objects as well, but they have to be explicitly defined and
hence separable from lists.) In python you have the same.

But of course, in a lesser language one would try to use some language
idiom to avoid that problem, such as "treat a specific variable as a
single/same type always". If not, you are asking for trouble. Much in
the same way as you need to learn the C pointer idioms before you can
handle pointers without problems.
Many language problems can be overcome by learning the proper idioms,
that does not mean that there does not exists better and safer solutions
for the problem than the idioms try to solve.

Java was designed to be type-aware from the beginning; making it untyped
would make it not Java. Sure, there are times when untyped languages
are more convenient; that's why they exist. For large applications
type-aware languages are very helpful. ....
That's part of why C++ has
gained traction over C, and why C# and Java are in their ascendancy.

I am not sure if what you are saying here makes any sense. But, the
reason why OO by way of C++ and C# and Java won is that C is not as
suitable for making business systems, which is what the majority of
programming in the world is about. C (and other procedural languages) is
better suited for system/technical programming.

When it comes to the type-aware languages argument, that has to do with
the fact that until recently (5-10 years ago) interpreted/type less
languages were slower and less efficient than compiled type safe
languages. So therefore type safe languages got more attention.

(As a side note. Today it is widely accepted, by academia and the best
system architects in the world, that the only way we can continue to
create more and more complex systems is if the programming languages and
tools develop so they can handle the increasing complexities of
programming and help the programmer do more in less time and with less
resources. A type less language is considered one of the developments
that can reduce the programming complexities by an order of magnitude.
Other developments are programming to interfaces, incremental
compilation, auto completion, auto build systems, iterative development
and many other auto magic tools that the computer can use to relieve
the programmer from mundane or complicating work).

tom