• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Extending the DB Interface

 
author
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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!
 
Ranch Hand
Posts: 119
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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 ]
 
Ranch Hand
Posts: 1033
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Greenhorn
Posts: 18
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
Posts: 580
5
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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
 
Ranch Hand
Posts: 85
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • 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.
 
Ranch Hand
Posts: 247
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I agree...I'm using the same design

Data implements extendedInterface

extendedInterface extends DBMain
 
reply
    Bookmark Topic Watch Topic
  • New Topic