Interface question B&S

[Yucca Nel]

After realising that the provided interface from Sun is lacking in certain methods like getAllRecords();(returns a list of all records in the databse);
and readSchema(); and findOffset(); I decided it logical to create a new interface designed for this this application. My Database access class is designed to be clean and allows for the databse to be swapped out with a commercial database. I therefore decided that it should not be a bad concept to code a interface for THIS database as surely and new database would need to have thier own interfaces too(DB Schema may differ).

So I would like your opinion on if my approach of having a more specific interface for my provided database that has all the same methods as sun + my own methods that return a list of all records and a method that reads the schema? I have been wanting to hardcode all DB schema info and this interface gives my Data.class a new way to validate all the schema as not only is the magic cookie important but so are a validation of all the field lengths etc. (to comply with the existing database that B&S use).

/*
 * To change this template, choose Tools | Templates
 * and open the template in the editor.
 */


package suncertify.db;

import java.util.List;

/**
 *
 * @author Yucca
 */
public interface BodgitAndScarperDB {
    /**
     * Reads a record from the file. Returns an array where each element is a
     * record value.
     * 
     * @return a <code>String[]</code> array where each element is a record
     * field.
     * @param recNo The record number of the record that is to be read from the
     * database.
     * @throws RecordNotFoundException if specified record does not exist or is
     * flagged as deleted in the database.
     */
    public String[] read(int recNo) throws RecordNotFoundException;

    /**
     * Modifies the fields of a record. The new value for field n appears in
     * data[n]. Throws SecurityException if the record is locked with a cookie
     * other than lockCookie.
     */
    public void update(int recNo, String[] data, long lockCookie)
            throws RecordNotFoundException, SecurityException;

    /**
     * Deletes a record, making the record number and associated disk storage
     * available for reuse.
     * Throws SecurityException if the record is locked with a cookie other than
     * lockCookie.
     */
    public void delete(int recNo, long lockCookie)
            throws RecordNotFoundException, SecurityException;

    /**
     * Returns an array of record numbers that match the specified criteria.
     * Field n in the database file is described by criteria[n]. A null value in
     * criteria[n] matches any field value. A non-null  value in criteria[n]
     * matches any field value that begins with criteria[n]. (For example,
     * "Fred" matches "Fred" or "Freddy".)
     * 
     * @return An arry of record number that match the search criteria.
     */
    public int[] find(String[] criteria);

    /**
     * Creates a new record in the database (possibly reusing a deleted entry).
     * Inserts the given data, and returns the record number of the new record.
     *
     * @param data The details of the record to be created in the db.
     * @return record Number of the newly added record.
     * @throws DuplicateKeyException If record number already exists.
     */
    public int create(String[] data) throws DuplicateKeyException;

    /**
     * Locks a record so that it can only be updated or deleted by this client.
     * Returned value is a cookie that must be used when the record is unlocked,
     * updated, or deleted. If the specified record is already locked by a
     * different client, the current thread gives up the CPU and consumes no CPU
     * cycles until the record is unlocked.
     *
     * @param recNo key of the record to be locked.
     * @return Cookie that must be used when the record is unlocked.
     * @throws RecordNotFoundException if specified record does not exist or is
     * flagged as deleted in the database.
     */
    public long lock(int recNo) throws RecordNotFoundException;

    /**
     * Releases the lock on a record. Cookie must be the cookie returned when
     * the record was locked; otherwise throws SecurityException.
     */
    public void unlock(int recNo, long cookie)
            throws RecordNotFoundException, SecurityException;
    
    /**
     * Returns all the records stored in the database.
     * 
     * @return A  <code>List</code> of all the Contractor records in the 
     * database. Null if there are no records.
     */
    public List findAllRecords();
    
    /**
     * Returns an array containing the database schema information.
     * 
     * @return an array containing the database schema information.
     */
    public Object[] readSchema();
}
    

[Mahesh Kumaraguru]

Your interface must extend the interface provided by Sun, then only your Data class will satisfy the requirement that it must implement the Sun Data interface. You only need to provide the new / extra methods you want in your interface, the methods from Sun's interface are available in your interface by the extends contract.

[Yucca Nel]

Are you sure? I don't think you are allowed to extend a modified interface an the Data MUST extend DB I need an interface that provides more data accessing operations so I decided to create a new interface that is implemented by Data that provides all the operations needed. Such an approach is also favourable if the Database gets swapped with a commercial database and will anyway need a different interface for that DB?

[K. Tsang]

If you want to add extra methods then the only way is to extend Sun's provided interface. Only this will satisfy "the Data class must implement this (provided) interface".

Also I don't think your findSchema method will be useful outside of your Data class. Because when you instantiate your Data class, you suppose to read the file header (magic cookie, field names, record length, etc) and put all that in instance variables of your Data class. At least that how I did my Data class.

[Yucca Nel]

But Data can still implement another interface(my custom interface) Thereby still complying with the must as it implements another interface. If you have a custom interface that extends DB then you still can not implement your custom interface as you need to meet the must requirement. YOU MUST implement DB it does not say ONLY DB. As for the readSchema such a method is only useful to read the data from the schema section but I have already hardcoded all this information. I only wish to use this method when I access my database and check ALL of my hardcoded values for correctness. Remember that the database must comply with the existing program which means that by checking it existing values against value that you intend to use then you varify that existing and new program data are compatible.

My file descriptor did not give me an offset and I need to read all data schema to get to where the records start. By hardcoding my offset I could be taking a guess, but a method that reads all data and then varifies all the information like my offset provide easier to understand code for junior programmers.

[Roberto Perillo]

Hey, partner.

Please take a look here. I think it might help you!

[K. Tsang]

Yucca Nel wrote:My file descriptor did not give me an offset and I need to read all data schema to get to where the records start. By hardcoding my offset I could be taking a guess, but a method that reads all data and then varifies all the information like my offset provide easier to understand code for junior programmers.

Like I said before, store the critical information about the file header as instance variables. So when first reading or instantiating:
1) read magic cookie value
2) record length
3) number of fields
4) field names
5) the file pointer of the first record

The subsequent access you can just use your pointer variable to calculate the record number SKIPPING the file header entirely. This will also make you make a decision - how often to read the magic cookie value to ensure it is the correct data file?

[Yucca Nel]

Thanks for the reply I am busy doing it as we speak(all the validating of my hardcoded values). I only do this when the database is provided by the user. Now i still have that question on my interface. I MUST implement DB so can that be an indirect implementation of a custom made interface that extends DB? I could just use the privided find method and call it with a null when my program starts but i would of thought having a method that returns a list would be recommended.

[K. Tsang]

Sun provided interface: SunInterface
Your own interface with additional methods: MyInterface

public interface SunInterface {  ... }
public interface MyInterface extends SunInterface { ... }
public class Data implements MyInterface { ... }

This will make Data class what ... a MyInterface and a SunInterface.

So using polymorphism you can set the type of Data class as MyInterface and SunInterface. But if declared as SunInterface you can't use your additonal methods.

  MyInterface data = new Data(); // good can use all methods in MyInterface and SunInterface
SunInterface data = new Data(); // bad cannot use methods defined in MyInterface  

[Yucca Nel]

I dont see the problem...

  1. public interface SunInterface {  ... }  
   2. public interface MyInterface extends SunInterface { ... }  
   3. public class Data implements MyInterface { ... }    

 #  MyInterface data = new Data(); // good can use all methods in MyInterface and SunInterface  
# SunInterface data = new Data(); // bad cannot use methods defined in MyInterface       

If MyInterface has all the methods of SunInterface declared exactly the same and if data...

  public class Data implements SunInterface, MyInterface {...}  

Then all it means is that with the one interface you can instantiate a different type of Data? This way Data has extra operations and still complies with MUST

[K. Tsang]

You better read the link Rob provided earlier. In that thread near the bottom:

The only problem with not extending Sun's interface and having your Data class implement the interfaces separately, like in:

public class Data implements YourInterface, SunsInterface

instead of

public class Data implements YourInterface

is that you won't be able to do this:

YourInterface data = new Data();
data.methodFromSunsInterface();

Bottom line: you can create your interface and extend Sun's interface without any problem. I did it and didn't fail!

[Yucca Nel]

But what about the "must" requirement?

Is there a huge difference in ....

 Data implements SI, MyI {...}
// We get to do this...
SI = new Data(); // Sun can continue to can do SI things
MyI = new Data(); // I can do my things + sun things because this interface has all the methods that sub has in theirs?  

Because I do not extend SI does not mean I can not code my own interface and use my own methods as well as SI methods if i include those in my Interface?

[K. Tsang]

First declaring 2 variables to instantiate the same class is bad. Maybe you know which variable to use but when other people look at it they would say "What the... why is it implemented that way?"

Think about polymorphism this way. Can a variable be a SunInterface and a MyInterface type at the same time?

Or think from the client side. Do you want the client to work with 2 separate variables or just one (with all accessible methods). By extending SunInterface is the way to go.

[Yucca Nel]

Hmm I am not sure, perhaps I just use the provided methods to get all the records to be super safe. If they say Must then Must is Must I am very confused now. I think about it and let you know..

It could be argued that a dog interface can be used when you want a dog and so can an animal interface but surely if your program needs a dog and you look at my two interfaces you should see that the dog interface is the one you "really" need.

Thank you for the time.

[Roel De Nijs]

Yucca Nel wrote:
If MyInterface has all the methods of SunInterface declared exactly the same and if data...

  public class Data implements SunInterface, MyInterface {...}  

Then all it means is that with the one interface you can instantiate a different type of Data? This way Data has extra operations and still complies with MUST

interface SunInterface {}
interface MyInterface extends SunInterface { 
   /* you are totally free to add to your own interface only your extra methods or 
    * legally override the methods from sun's interface 
    */
}
class Data implements MyInterface {}

this also complies with the must, because (Data instanceof SunInterface) will return true if you put SunInterface in the correct package of course and that's exactly the test they will execute to test this must. And if you read the stories about those who passed the past weeks/months you will notice that lots of them have extended sun's interface