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.
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.
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.
Joined: Jan 29, 2003
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?
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
Joined: Aug 19, 2005
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.
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).