• Post Reply Bookmark Topic Watch Topic
  • New Topic

Overriding hashCode(), equals() etc. when composing rather than inheriting.  RSS feed

 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

I just came across the problem that when I use composition rather than inheritance, I won't be able take advantage of toString(), hashCode() etc. without creating delegating methods.

That seems cumbersome to me, is there any way to forego that ?

As an example, I came up with my own implementation of ResultSet by implementing the interface, delegating most of the methods and providing my own form where necessary. In order to use the finalizer which closes the ResultSet in case the client did not, I will have to override finalize manually and call finalize() on the composed instance.
 
Campbell Ritchie
Marshal
Posts: 56546
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
You are asking about equals() and then talk about finalize().

In a ResultSet, do you need to override equals() and hashCode() at all? Is a ResultSet really formed by composition? If you have a class which is formed by composition, you can easily call equals() and hashCode() on the composite objects (which would doubtless be [?instance?] fields), assuming those classes have correctly-overridden methods themselves. Similarly those composite parts would have toString methods which you can call. Surely you don't need delegate methods?Apart from the fact that I left a serious error in that code, do you really need a delegate method?
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hey,

sorry for confusing you with hashCode, equals and finalize.

Since they're all inherited from object I mingled them together.

As a matter of fact I don't even need to override hashCode and equals in my case.

Here is my scenario:

- I came up with a little JDBCSupport framework that pools connections, does not close them when a query has finished but puts them into an IDLE pool to speed things up.
- When a Connection is closed, it should not really close, but rather release the Connection back into the pool of idle connections.

So what I came up with was..




As far as I know, the implementation of Connections closes the connection in the finalizer in case the client forgets that.
With my implementation this won't happen unless I delegate it.



This seems a little clumsy to me, or is that the conventional way of doing it?

PS: the reason why I talked about ResultSet earlier is because I use a similar approach with it, but I figured the Connection example makes it clearer.

Thanks for help .
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I just figured out I can't even call finalize since it's protected...
 
Campbell Ritchie
Marshal
Posts: 56546
172
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Don't know. Sorry.
 
Sebastian Janisch
Ranch Hand
Posts: 1183
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Sometimes I think I'm retarded...
As soon as JdbcSupportConnection goes out of scope the associated Connection will too and hence it's finalizer is called.

Gee ...
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!