This week's book giveaway is in the Agile and Other Processes forum.
We're giving away four copies of The Little Book of Impediments (e-book only) and have Tom Perry on-line!
See this thread for details.
Win a copy of The Little Book of Impediments (e-book only) this week in the Agile and Other Processes forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Extending the DB Interface

 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Although it isn't absolutely essential, I'd like extend the DB interface to add a few more methods (most notably for resource cleanup because I'll be using synchronous I/O instead of caching in to make the database server less susceptible to sudden JM crashes). Since the Data class will still indirectly implement the unmodified DB interface, I should still be OK right?

Anyone have any insight about the issue? I've read through the first few dozen pages of posts but could not find anything concrete. I could just manipulate my concrete Data class in my server-side facade, so I don't want to get in hot water unneccessarily...

Thanks in advance for your help!
 
Liang Anmian
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I will advise you to e-mail Sun Microsystems or Prometric regarding this issue. They may or may not treat this as a modification to their DB interface. If they do, it's an immediate failure. Better not risk this.

One way you can consider is implement those extra methods inside your concrete class instead of the DB interface. Is it feasible for your case?
[ February 03, 2005: Message edited by: Liang Anmian ]
 
peter wooster
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Reza Rahman:
Although it isn't absolutely essential, I'd like extend the DB interface to add a few more methods (most notably for resource cleanup because I'll be using synchronous I/O instead of caching in to make the database server less susceptible to sudden JM crashes). Since the Data class will still indirectly implement the unmodified DB interface, I should still be OK right?

Anyone have any insight about the issue? I've read through the first few dozen pages of posts but could not find anything concrete. I could just manipulate my concrete Data class in my server-side facade, so I don't want to get in hot water unneccessarily...

Thanks in advance for your help!


You should not modify or extend the DB interface. If you do, its possible that code Sun will try to use in conjunction with your code will fail. What I did was to define a Session interface that describes the session related methods. My Data and DataProxy classes implement Session and the interface provided by Sun.
 
Ryan Tang
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Reza Rahman:
Although it isn't absolutely essential, I'd like extend the DB interface to add a few more methods (most notably for resource cleanup because I'll be using synchronous I/O instead of caching in to make the database server less susceptible to sudden JM crashes). Since the Data class will still indirectly implement the unmodified DB interface, I should still be OK right?

To play safe, I create another interface, Database, which has all the methods in DB AND other methods that I think useful, says closing the database file. The database access class, Data, implements BOTH Database and DB interfaces DIRECTLY.

Ryan
 
Reza Rahman
author
Ranch Hand
Posts: 580
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Guys:

Thank you very much for your input. I have decided to use the Adapter pattern and use the concrete implementation of DB directly, bypassing the DB interface limitations altogether. I still wonder about extending the interface though...maybe this can be left for a braver soul?

Reza
 
Dieskun Koper
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hello Reza,

I extended the DBMain interface with another interface with methods that I found were missing, such as another find method. My Data.java class implemented this interface (and so indirectly the DBMain interface).

I don't understand why others are so worried about this design.
There is nothing in the instructions against it, I passed with this solution, and the Java API is full of such solutions:
LayoutManager2 -> LayoutManager
List -> Collection
SortedSet -> Set -> Collection

It's plain O-O.
 
Kris Reid
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I agree...I'm using the same design

Data implements extendedInterface

extendedInterface extends DBMain
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic