aspose file tools*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Can my Data class implement an interface which extends the DataAccess interface? Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Can my Data class implement an interface which extends the DataAccess interface?" Watch "Can my Data class implement an interface which extends the DataAccess interface?" New topic
Author

Can my Data class implement an interface which extends the DataAccess interface?

pkinuk Buler
Ranch Hand

Joined: May 22, 2009
Posts: 63
Hi, folks.

Can my Data class implement an interface which extends the DataAccess interface?

Because my assignment states that: Your data access class must be called "Data.java", must implement the following interface DBAccess: . I'm a little bit confused about this.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

Hi pkinuk,

Yes, it can. I followed same approach.


So the Data class indirectly implements the DBAccess interface, so you are not violating the must requirement.

Kind regards,
Roel


SCJA, SCJP (1.4 | 5.0 | 6.0), SCJD
http://www.javaroe.be/
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

In fact, most of the people do that, in order to overcome some of the limitations that are implicitly present in the interface provided by Sun.


Cheers, Bob "John Lennon" Perillo
SCJP, SCWCD, SCJD, SCBCD - Daileon: A Tool for Enabling Domain Annotations
Naveen Narayanan
Ranch Hand

Joined: Sep 11, 2007
Posts: 114

I also did somewhat similar, Data-->MyInterface-->SUNInterface
Probably I couldn't find no other way out


SCJP 5.0, SCJD, SCWCD
mohamed sulibi
Ranch Hand

Joined: Sep 04, 2005
Posts: 169
Hi All;

in my opinion i think there are two solutions to the limitation in the interface provided:
1- Create anew intermediate interface that will contains news methods and used in the local/remote mode (ex. Data-->MyInterface-->SUNInterface), OR
2- Use adapter design pattern to Adapt an instance of SUNInterface to a new interface (MyInterface) and use this instance in local/remote mode.

In solution one you must provide implementation for all public methods in the Data class and another methods specific to you context.
but in solution two you provide only specific methods that will use the public method of the data class, and in this solution the GUI client are limited to specific methods that provide desire functionality.

Best Regards.
Mohamed Sulibi
SCJP, SCJD, SCWCD in progress.
Bernd Wollny
Ranch Hand

Joined: May 15, 2006
Posts: 59

Hi all,

Roel and Roberto, you gurus... , in my implementation i currently have to choose between those two options described by mohamed. At the moment, my solution looks like mohameds second one: i have a remote adapter which adapts my remote interface and implements SUN's interface. You both wrote you would prefer the first one, can you explain why? Are there any disadvantages within the second approach i can't see at the moment?

Best regards,
Bernd


SCJP 1.4, SCJD/OCMJD
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

Hi Bernd,

Could you give a small sample of the structure your interfaces and Data class are connected together (like I did in my post above)? That will make it easier to understand and respond (without communication errors).

Kind regards,
Roel
Bernd Wollny
Ranch Hand

Joined: May 15, 2006
Posts: 59

Hi Roel,

of course i can....here it goes...

In local mode i instantiate Data directly, in remote mode my factory returns an instance of DatabaseRemoteImpl (DatabaseRemoteImpl itself creates an instance of Data), my DatabaseRemoteAdapter adapts the DatabaseRemoteImpl instance and handles RemoteExceptions...
My factory is the class i bind to rmi registry.
Any comments?

Regards
Bernd
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

Hi Bernd,

I guess it all depends on what you need to make your solution work. I needed for example a method to initialize my record cache (read records and build a map containing this records). As far as I know you need your own interface to do something like that, and you can't solve it with using the Adapter pattern (because there isn't a suitable method in the original sun interface to call).

And I guess you are making a thick client (expose read, lock and other methods in your DatabaseRemote interface)? I used a thin client so I had a BusinessService method containing just 2 methods for my assignment (find and book). So that's a completely other approach as you, but yours is just as good (even more appropriate according to the instructions and Andrew Monkhouse his opinion about exposing lock/unlock methods to the client, you can read the big discussion here).

Kind regards,
Roel
Bernd Wollny
Ranch Hand

Joined: May 15, 2006
Posts: 59

Hi Roel,

yes you are right i'm making a thick client, i have all methods (lock, unlock, read,...) in my interfaces DBMain and DatabaseRemote. They have the equivalent methods and only differ in throwing RemoteExceptions or not. I think that Mohamed is right, there are (only) those two common ways to overcome SUN's interface limitations. I was wondering why you decided for solution #1. But, as you said, it strongly depends on what client you want to have and how your locking strategy looks like and yours is completely different to mine. I will continue this way and let you know if it was ok (or not)...

Regards
Bernd

BTW, all i want to hear from you is that i am not on the woodway and to keep my mind free from all that certification stuff....
No, just kidding...
Roberto Perillo
Bartender

Joined: Dec 28, 2007
Posts: 2265
    
    3

I too opted for a thick client... but if it was today, I'd prepare a thin client. I think it eases the implementation, the API that is provided to the client side gets simpler and the services become more useful. When I studied the Exposed Domain Model pattern, I thought that it was too complicated to control transactions and the ORM framework in the web tier... in my opinion, there's some equivalence with us creating a thick client. The lock() method is equivalent to the start of a transaction (and that is why I think it must not be called from the update() or delete() methods), and I don't know... I think it is easier to have a thin client. It's simpler... in my opinion.
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

Roberto Perillo wrote:I think it is easier to have a thin client. It's simpler... in my opinion.

I can't agree more
Bernd Wollny
Ranch Hand

Joined: May 15, 2006
Posts: 59

Hi!

Roel, you said you extended SUN's interface and your Data class implements your own interface. But why? As you said here you put another tier between client an db access, your business layer with only two methods, book and find. so what's the role of your new own interface? You followed the 3-tier-approach described in your posted link, i'm going to have a 2-tier-app (thin and thick). Can you please explain whats the role of your interface, do you have an example?

Kind regards
Bernd
Roel De Nijs
Bartender

Joined: Jul 19, 2004
Posts: 5286
    
  13

Hello Bernd,

I already indicated in my previous post why I needed my own interface, but apparently I didn't explain it very well, so I give it another shot

I opted for a singleton Data class with a record cache (a map containing the database records). In my opinion that's the easiest and simplest approach possible (for example you don't have to cope with IOExceptions in read, update,... methods). So before you can call the read-method on your Data instance you have to first initialize (and populate) the record cache. So in Sun's interface there isn't any method suitable to do this, so I created my own interface:

And of course I needed also a method to write the records from the cache back to the file (invoked when the server is stopped or the standalone application exits).

I also redefined some methods from Sun's interface. More info about this approach you can read in this thread.

Kind regards,
Roel
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Can my Data class implement an interface which extends the DataAccess interface?