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).
SCJP 6.0, SCJD (400/400), SCBCD for JEE 5, SCWCD 1.4 I do videos for development at
I am probably the only developer ever to have had an orange sized brain tumor in my brain while learning development!!
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.
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?
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.
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.
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?
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.
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.
Yucca Nel wrote:
If MyInterface has all the methods of SunInterface declared exactly the same and if data...
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
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