Meaningless Drivel is fun!*
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes B&S: find/search 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 "B&S: find/search" Watch "B&S: find/search" New topic
Author

B&S: find/search

Muhammad Shafique
Ranch Hand

Joined: Sep 30, 2006
Posts: 59
Hi Folks,
Is it a good idea to add more methods in DBMain interface? find method of DBMain returns only record numbers but we need records data to display on JTable at client side.
It can be done at client too after getting record numbers but I am not sure which approach is better. Please comment!!!

Regards,
Shafique
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
no, you're not allowed to.
You ARE allowed to extend the interface and put extra methods in that new interface.


42
Muhammad Shafique
Ranch Hand

Joined: Sep 30, 2006
Posts: 59
Thanks Jeroen for your prompt reply!!
My specs say:
[Your data access class must be called "Data.java", must be in a package called "suncertify.db", and must implement the following interface (which is DBMain)].

Now if some interface ABC extends DBMain then Data.java should implement ABC. In this case Data.java is not directly implementing DBMain which may be an automatic failure.
There could be one more option that I create a new interface XYZ with some new required methods and don't extends DBMain. After that I create a new class lets say Data2.java which extends Data.java and implements XYZ but in this case Data2.java is the access class and not Data.java.

I am not a professional programmer and don't know about such things in details so please help me to take a proper decision before I go ahead.

Many thanks!
Shafique
Muhammad Shafique
Ranch Hand

Joined: Sep 30, 2006
Posts: 59
I got another idea. What if I create another interface ABC and don't extend DBMain and Data.java should implement both interfaces.

Comments??
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
where does it say Data MUST DIRECTLY implement DBMain?

Unless it says that explicitly there is no requirement to implement it directly, as long as you implement it.
Might be a bit sneaky, but if the requirements are vague (and they are, deliberately so), I see no reason to interpret them more strictly than they're written down.

Having Data implement 2 interfaces is of course also an option, but IMO is in this case less clean as the 2nd interface is a natural extension of the first rather than some additional functionality.
It also makes writing the rest of the application to an interface harder as you'll be constantly juggling to convert from one to the other when needing functionality provided in either interface.

What I have done is as follows:
I've created a DecoratedDB interface extending the DB interface (which your assignment calls DBMain, the very name of which suggests to me that there are derived interfaces from it) with several more methods (including a search method returning entire records, a method to get the lock manager, and methods to get metadata).
Data implements that interface and forwards most calls to a DataFile object which is injected into it through the constructor.
The factory which creates the Data object takes care to create the correct class of DataFile (which is abstract) for the database format (of which there is only one of course).

The client has its own factory to get a reference to a Data object. That factory will either return that reference directly or get one from the server through RMI and wrap that stub in a proxy which hides the network components, so the client doesn't have to catch networking errors (they're wrapped in standard exceptions by the proxy).

It might be a bit overengineered, but it's so flexible that as it stands (and that could be changed if using something like Spring based dependency injection) only a single class on the client needs to be changed to switch from RMI to some other networking mode (of course a few new classes are also required to provide for the communication with that other network, but the interfaces they should provide already exist).
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
Is it a good idea to add more methods in DBMain interface? find method of DBMain returns only record numbers but we need records data to display on JTable at client side.
It can be done at client too after getting record numbers but I am not sure which approach is better. Please comment!!!


You don't need new methods. Use readRecord(recNo) and build the record data list at the server side and send them back to the client.
Muhammad Shafique
Ranch Hand

Joined: Sep 30, 2006
Posts: 59
Thanks Mike & Jeroen!
Mike;
Return types of read and find methods are String[] and int[] respectively. If you see client side, its seems difficult. How client can know the number of matched records to loop read? Putting everything (all records) in single String[] and then sending it to client does not seem a good idea. Do you think calling first find from client side and then loop read is a good approach, where our DB is sync?

Jeroen;
You are right, it does not say MUST DIRECTLY but it does not say indirectly too thats why I am skeptical and perhaps over carefull! Your idea of not having two interfaces is quite appealing. Although there is separate layer to take care of remote clients but in local mode, switching of interfaces is not a good idea when this layer is bypassed. But do we need to switch between interface in local mode? I think we can use Data object in local mode to get all services. What is your opinion? And thanks for your detailed reply!!
Mike Ngo
Ranch Hand

Joined: Oct 16, 2006
Posts: 89
Do you think calling first find from client side and then loop read is a good approach, where our DB is sync?


No, it is not. For ex, if you have 20 matched records, you will make 21 network calls to get the results (1 call for the find() and 20 calls to retrieve the record data).

Return types of read and find methods are String[] and int[] respectively. If you see client side, its seems difficult. How client can know the number of matched records to loop read? Putting everything (all records) in single String[] and then sending it to client does not seem a good idea.


The client should ask the server to do the search and return the result in ONE network call.
Your method should be something like this:
ArrayList<RecordData> searchRecord(criteria)
where searchRecord() will call find() to get a long[] and loop thru the array and call get() and build and return the ArrayList<RecordData>
Muhammad Shafique
Ranch Hand

Joined: Sep 30, 2006
Posts: 59
Thanks Mike for your help, I got the idea.
Jeroen T Wenting
Ranch Hand

Joined: Apr 21, 2006
Posts: 1847
I do contest the List<Record> returntype (returning ArrayList<Record> would be even worse, Collection<Record> slightly better).

At least in my design the DB interface knows nothing about what it's returning, so returning a specific type (rather than a Collection of String arrays) is a bad idea.
You can of course create a Record interface and return that, with the server implementation knowing what actual type it is, but that would be just a marker interface and IMO an ugly solution.
Muhammad Shafique
Ranch Hand

Joined: Sep 30, 2006
Posts: 59
Mike,
I want to avoid 21 network calls. Thats why I want to add another interface and want Data class to extend it too. From your last message it seems to me that ArrayList<RecordData> should be built at client side if I don't want to change DBMain or add another interface (directly or indirectly). There is no method like ArrayList<RecordData> searchRecord(criteria) in DBMain. I want to do evertying in just a single call. There are some filteration involved on client side too. Sun's specifications are quite vague. I want to put more load on server and less on netwrok although efficieny is not required. Client should not send more calls to server to fetch records one by one.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S: find/search
 
Similar Threads
URLyBird 1.3.3 - a few questions
How to get the recNo from client's record displaying talbe?
No readAll methods provided
Exact match and starts with
NX: URLy Bird 1.3.1 Hashmap (or Hashtable)