This week's giveaway is in the Android forum.
We're giving away four copies of Android Security Essentials Live Lessons and have Godfrey Nolan on-line!
See this thread for details.
The moose likes OO, Patterns, UML and Refactoring and the fly likes Interface combinations ... Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Interface combinations ..." Watch "Interface combinations ..." New topic
Author

Interface combinations ...

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I have some little data utility objects in a tiny app. You hand one to the sql executor and the executor orchestrates the details with callbacks to get what it needs. All the get and close connection stuff is neatly hidden away in the executor.

All of them have getSql() that returns a SQL statement as String.

Some of them have setParameters(PreparedStatement) to set parameters.

The "get" (select) objects have acceptResultSet(ResultSet) to copy data from rs to application objects. The "put" (update and insert) objects do not.

These grew over time and now I have interfaces for four kinds of little objects: get, put, getWithPrepStmt, putWithPrepStmt (not the real names).

I kinda like the little buggers because they put all the code that has to know database table and column names in one place. But the four interfaces seems clumsy. Waddya think?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5

Interface-Segregation Principle: Clients should not be forced to depend on methods that they do not use.


Are there interfaces that all your clients use together and you can't envision a client that is only going to use one of them? Then merge them. If there are interfaces that tend to be used together then also create a new one that aggregates them and extend the aggregate interface so that you always clearly communicate what your intentions are.

Otherwise leave it alone. Just my opinion.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I think I'm ok with leaving them alone for now. As often happens, a troubling piece of code doesn't bother me so much after a couple days doing something else. Maybe it will again later.

Something just sprouted up on my "emerging" design today. A couple of updates will hit two tables and need transactions. Looks like the update variants have a flag for "needs transaction". Oh, or maybe they'll ALL get transactions. Heh heh.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
I wanted to bring a pure fantasy idea into this at some point. I guess other languages do it, but not Java: Specify a parameter type as a combination of interfaces instead of one type. What do you suppose that would look like?
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5


Output:

Executing UpdateHandler
Executing PreparedHandler
Executing QueryHandler


As long as you can move a different interface into the first position of the multiple bounds for the type parameter you are fine - otherwise you are out of options. Try to throw in:


You'll be faced with:

MultiInf.java:32: name clash: <QueryHandler>execute(QueryHandler) and <AnotherHandler>execute(AnotherHandler) have the same erasure
Peer Reynders
Bartender

Joined: Aug 19, 2005
Posts: 2922
    
    5
Here is an example in Scala, an object-oriented and functional language that compiles to the JVM and is fully interoperable with Java.


Scala's traits are more than just interfaces, they can carry code so they can almost be used like aspects (which can be overridden by the class using them). The first book Programming with Scala is available as a PrePrint edition. They hope to have the dead-tree version ready by this year's JavaOne.

Reusability of existing Java code is a crucial objective in Scala's design - that's if it is worth reusing:
Scala and Java Living Together, Mass Hysteria: msg#00023
In a depressingly-large number of cases we have found bugs in third-party code which have forced us to abandon using it and rewrite the whole thing in Scala. This is evidence that we perhaps have a rather heavy-handed approach to "making stuff work", but I think it demonstrates Scala's stability.


Anyway, it looks like that Scala is worth keeping an eye on - it has certainly preempted and easily surpassed my somewhat tepid interest in Groovy (which now seems to be a big part of IBM's Project Zero).
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Interface combinations ...
 
Similar Threads
response time
confused...
help in having 'n' BlockedQueues and 'm' threads
how to let 10 thread do the same thing simultaneously ?
JavaBean - what it exactly is like?