Win a copy of TDD for a Shopping Website LiveProject this week in the Testing forum!
  • 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
  • Paul Clapham
  • Ron McLeod
  • Jeanne Boyarsky
  • Tim Cooke
Sheriffs:
  • Liutauras Vilda
  • paul wheaton
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Stephan van Hulst
  • Carey Brown
  • Frits Walraven
Bartenders:
  • Piet Souris
  • Himai Minh

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
 
When evil is afoot and you don't have any arms you gotta be hip and do the legwork, but always kick some ... tiny ad:
Free, earth friendly heat - from the CodeRanch trailboss
https://www.kickstarter.com/projects/paulwheaton/free-heat
reply
    Bookmark Topic Watch Topic
  • New Topic