FBNS: Inherit from Data class and How to operate db.db

[George Ren]

Hi,everyone,
I have two questions.
1. What do me inherit the Data Class for? Is that for implement the lock(), unlock()and criteriaFind(String criteria) methods?
2.I find there are many columns in db.db file.My question should be, How to operate the db.db? How do the RandomAccessFile operate the db.db and filter the name of each columns and how to add a new Flight information into the binery file?

Thank u in advance!
Regards,
George

[Andrew Monkhouse]

Hi George,

What do me inherit the Data Class for?

I think you are asking what reasons could there be for extending the Data class?
One reason is to implement the lock() unlock() and criteriaFind() methods. The instructions do give you the option of implementing them in the Data class itself, or by extending the Data class and implementing them in the the extended class. You have to document why you did this.
Another reason could be if you wanted to create additional methods for dealing with the database. Your instructons tell you that the Data class is complete with the exception of the lock() unlock() and criteriaFind() methods, so additional methods should not be added to the Data class. But you could add them to your extended class.

How to operate the db.db?

That is what the Data class provides for you - methods by which you can access the db.db. You can use the constructor which takes the name of the file to open, then call the desired method to work with the data.
Regards, Andrew

[George Ren]

Thanks Andrew. I think I understand the functionality of the inherited class.
But I think the Data class is only the implementation class. So do we have to make the Data class implements a interface? Maybe named as FlyModel, using the MVC design pattern.
In FlyModel, we only decalare methods in the Data class.
Pls guide me.
Thanks.

Regards,
George

[Andrew Monkhouse]

Hi George

So do we have to make the Data class implements a interface?

I dont understand why you would want to do this. The Data class has already been written for you, so you do not have to make it implement any interface.
Dont confuse this assignment where you are given a written Data class with the NX assignments, where the candidates have to write their own Data class and implement an interface - you do not have to do that.
Regards, Andrew

[Patrick Cobbett]

I think you'll find that Sun anticipates you to declare criteriaFind() an abstract method. There is no need to declare lock() and unlock() abstract as the required behaviour is well defined and this would mean implementing or atleast re-writing locking code every time you implement criteriaFind(). By declaring criteriaFind() an abstract method in Data this allows subclasses to define different ways to query the database. If as the requirements specifies, the user-interface should be designed with the expectation of future funtionality enhancements, then the database may need to be queried in increasingly complex ways.
There's no need to concern yourself with how to read and write to the database file as this is implemented for you.

[George Ren]

Andrew,
Maybe I don't understand your explaination.
In the MVC design pattern there should be three interfaces which are FlyModel, FlyController and FlyView. And we must wirte implementation class for the three interfaces. And I consider Data class the implementation class of FlyMedel interface. So I want the Data class to implement a interface to meet the MVC design pattern.
Maybe I have a wrong understanding of MVC,so pls guide me. Thanks.

Hi,Patrick,

I think you'll find that Sun anticipates you to declare criteriaFind() an abstract method.

But I think in the specification of the project, SUN said the data class is complete, so u mustn't modify any existing methods.

Regards,
George

[Andrew Monkhouse]

Hi George,
OK, I think I understand your question now.

In the MVC design pattern there should be three interfaces which are FlyModel, FlyController and FlyView. And we must wirte implementation class for the three interfaces.

Interfaces (and coding to them) is a good thing. But don't get too carried away: you do not have to create interfaces for every class you write. I also used MVC (well HMVC) in my solution, but I did not create any interfaces at all in the client package. I did use some interfaces (such as Observable) but I I did not create any.
(I did create some interfaces in the connectivity package, and others in the server package, but that is a different story).
I wrote my model using the push model, where the model pushed data out to views whenever it needed to. This meant that the views did not need to know any of the methods of the model (apart from Observable), so I did not need to create an interface for the model for the views to code to.
However I can see that if you were using the pull model, or if your views were calling methods in the model to access static data, then it might be wise to create an interface for the model that the view can code to.

And I consider Data class the implementation class of FlyMedel interface.

I think that Data class is not the model in your MVC for two reasons:

You cannot always use Data as the model.

The Data class provides access to any database - it is not specific to your needs.

Taking them in turn:
You cannot always use Data as the model. You have to provide both local and remote access to your database. So if you have Data as your model for local mode, then you are going to have to swap the model completely to run in networked mode. While this is achievable, I dont believe it is the right way to go. Especially when taken with the next point.
The Data class provides access to any database - it is not specific to your needs. The Sun MVC blueprint describes the functionality of the model as "The model represents enterprise data and the business rules that govern access to and updates of this data". So the model is where I would expect to find methods relating to flights. The model would then translate that request for booking a flight into calls to the appropriate classes and methods to perform the booking. So the model might call the lock(), read(), modify() and unlock() methods of the Data class. The model is acting as a facade to your database(s).

So I want the Data class to implement a interface to meet the MVC design pattern.

Again, two issues:

As I said before, I dont think the Data class is your model.

I don't think you should be modifying the Data class to make it implement your interface. The Data class is meant to be complete with the exception of three methods.

I also agree that criteriaFind should not be declared abstract. Doing so would force the Data class to be declared abstract which is stoping it from being a "complete" class. Even if you implement a version of criteriaFind in the Data class, a class which extends Data class could always override the criteriaFind method if they wanted a different implementation.
Regards, Andrew

[Patrick Cobbett]

Hi George,

But I think in the specification of the project, SUN said the data class is complete, so u mustn't modify any existing methods.

You are correct in saying that implemented methods should not be modifyed but the requirements specifies the following:

Part of your assignment will be to enhance the Data class. You may do this by modification or subclassing, but you should document the approach and reason for your choice.

Hi Andrew, your comment

I also agree that criteriaFind should not be declared abstract. Doing so would force the Data class to be declared abstract which is stoping it from being a "complete" class. Even if you implement a version of criteriaFind in the Data class, a class which extends Data class could always override the criteriaFind method if they wanted a different implementation.

The requirements says:

Three classes are in this package: Data, DataInfo, and FieldInfo. With the exception of three methods, noted below, these classes are complete and functional, and you have the source code for them.

I think that the Data class should be designed for extension. I'm guessing you've also kept it's members private. How would you override the criteriaFind() if you do not have access to the file pointer? Searching for records using getRecord(int) is a costly way, creating instances of DataInfo even for records which do not satisfy the criteria. As searching the database in this manner is where the server will spend much of it's time and the number of records could potentially get quite large it may not be feasible.
The way you are suggesting would not make it feasible to alter the behaviour of that method. Are you suggesting that we should only be able to query the database using exact match querys?
From a different angle, the requirements specifices that the user-interface should be desgined with the expectation of future functionality enhancements. Surely these functionality enhancements may wish to query the database in increasingly complex ways?
It is my opinion that Data should be abstract to enable subclasses to define specific query languages. This requires the loosening of access to read() and readRecord() to protected, much like may other classes designed for extension in the swing API.

[Andrew Monkhouse]

Hi Patrick
I can see your point of view, even though I don't agree with it.

I think that the Data class should be designed for extension. I'm guessing you've also kept it's members private. How would you override the criteriaFind() if you do not have access to the file pointer? Searching for records using getRecord(int) is a costly way, creating instances of DataInfo even for records which do not satisfy the criteria. As searching the database in this manner is where the server will spend much of it's time and the number of records could potentially get quite large it may not be feasible.

It is possible to use getRecord(int) to do the searching. And it might actually be better to do that in a large database than to use the readRecord() method which I think you are suggesting? readRecord() has no knowledge of what record it is currently pointing at - it just reads the current record. Therefore the entire criteriaFind() method would have to be synchronized to ensure that the record pointer is not moved by any other methods. This means that the criteriaFind method becomes a potential bottleneck. Whereas getRecord(int) specifies exactly which record is to be retrieved - so you could write a version of criteriaFind external to the Data class (you would have to do it in a thread safe way of course) that does not need to be synchronized - so the database is not blocked by the person doing a criteriaFind() call.
Also, if modifications are required in the future, and we decided that we needed a new version of criteriaFind (or any other method), and we decided that it should use the low level readRecord() method, then I would prefer to change the access on the Data class at that time to give them package level access. That way I could extend the class, while no current classes using Data would be affected.

The way you are suggesting would not make it feasible to alter the behaviour of that method. Are you suggesting that we should only be able to query the database using exact match querys?

The problem here is an assumption about what might be required in the future. Now if a later change was to allow partial matches on fields, then perhaps we could do it by creating an overloaded criteriaFind within the Data class itself. Why does it have to be in an extended class?

From a different angle, the requirements specifices that the user-interface should be desgined with the expectation of future functionality enhancements. Surely these functionality enhancements may wish to query the database in increasingly complex ways?

Sure. But does that mean that for each enhancement you create a new extended class? Or that you enhance an existing class?
I cannot see how implementing criteriaFind() inside the Data class precludes later enhancements, or that making Data class abstract makes it easier to enhance later.

It is my opinion that Data should be abstract to enable subclasses to define specific query languages.

What happens if there are existing applications that are using Data class? We have not been told that there are no other applications - there could be a reporting application and a bulk data entry program already written. Since we have been given a database that already contains records, it is quite likely that there is at least one other application out there than can access the database, possibly through the use of the Data class. You will have just broken that other application.

these classes are complete and functional

Making Data class abstract stops it from being functional.
Regards, Andrew

[Patrick Cobbett]

Hi Andrew,

It is possible to use getRecord(int) to do the searching. And it might actually be better to do that in a large database than to use the readRecord() method which I think you are suggesting? readRecord() has no knowledge of what record it is currently pointing at - it just reads the current record.

The truth is, as far as filtering read records are concerned, there is an unncessary over-head when reading records using readRecord(). I guess you create a DataInfo instance, then call getValues(), and then filter making use of the returned String[]? .. when you could call readRecord() directly to obtain this String[].
Admittedly, criteriaFind() does need synchronizing (or atleast it's core functionality) but it is recursively executing readRecord() and seek(), which need to be synchronized as a whole. You'll find that this is what the method find() already implemented does.

Therefore the entire criteriaFind() method would have to be synchronized to ensure that the record pointer is not moved by any other methods. This means that the criteriaFind method becomes a potential bottleneck.

I personally have synchronized the whole method because i think that each client might as well get it's query done in one go rather than being interrupted imbetween. However it is possible to read in all the records using readRecord() in a single synchronized block before filtering them as results to the client. Synchronizing as a whole also guarantees that the client gets the most recent/update record values from it's query.

Also, if modifications are required in the future, and we decided that we needed a new version of criteriaFind (or any other method), and we decided that it should use the low level readRecord() method, then I would prefer to change the access on the Data class at that time to give them package level access. That way I could extend the class, while no current classes using Data would be affected.

You make out that i'm making alot of assmuptions here, but there is really only one assumption- that the Data class's functionality does need to be extended, or atleast extendable.
Perhaps i'm taking OCP a bit too far here but your opinion suggests that the existing code would need to be modifyed rather than being extended.

The problem here is an assumption about what might be required in the future. Now if a later change was to allow partial matches on fields, then perhaps we could do it by creating an overloaded criteriaFind within the Data class itself. Why does it have to be in an extended class?

No comment here except that this a violation of OCP.
It would seem however that exact match queries would be reasonable for any derivative language. Perhaps we should just extend the default implementation? It's just that if the class is designed for extension, and hence methods need to be protected, then we'd might aswell not tie ourselves down to any default implementation.

Sure. But does that mean that for each enhancement you create a new extended class? Or that you enhance an existing class?

You discuss breaking clients. But by extending an existing class you will be breaking the existing contract and hence break clients which depended on that contract. Joshua Bloch discusses that when you override a method you are declaring that a class is not a more specific type of it's parent class but rather has a special behaviour for a special purpose. (Sorry, not exact quote as book is not handy.)

I cannot see how implementing criteriaFind() inside the Data class precludes later enhancements, or that making Data class abstract makes it easier to enhance later.

The way i see it is that the Data class class provides functionality to read and write to the database. This on it's own is cohesive enough to justify a single responsiblity for it's existance. What i am suggesting is that it should make no assumptions about ways inwhich you can query it using a query string. The requirements specifies that we should implement this method in Data or by extension. I propose loosening the contract in the Data class method criteriaFind() to declare that the way inwhich the criteriaFind() is interpreted is dependant on subclasses. My class DefaultData is an implementation which uses exact matches.

What happens if there are existing applications that are using Data class? We have not been told that there are no other applications - there could be a reporting application and a bulk data entry program already written. Since we have been given a database that already contains records, it is quite likely that there is at least one other application out there than can access the database, possibly through the use of the Data class. You will have just broken that other application.

.. Not if the contract on Data is loosening as explained just now.
Ok, to best explain where i'm coming from i use the anology with the Driver class in JDBC. The Connection class, obtained by calling getConnection() on Driver has a method executeQuery(String query). This does mean that clients SHOULD know what implementation of Data they are communicating with much like clients of Connection in JDBC should know which type of database they are communicating(resulting in different SQL syntax).

Making Data class abstract stops it from being functional.

You explain that the requirements specifies that the Data class is already fully functional and that making it abstract prevents it from being fully funtional. Why then does is it also mention that we can implement criteriaFind() by modification(in the Data class) or by extension(in sublasses)?
You comments are highly valued, please give me opinions about what i have said as some of it has just been thrown in to the air!

[Andrew Monkhouse]

Hi Patrick,

Andrew: Therefore the entire criteriaFind() method would have to be synchronized to ensure that the record pointer is not moved by any other methods. This means that the criteriaFind method becomes a potential bottleneck.
Patrick: I personally have synchronized the whole method because i think that each client might as well get it's query done in one go rather than being interrupted inbetween.

OK - there is nothing in the specifications to go either way here. You could be right with getting it all done as quickly as possible, or I could be right in allowing other methods to be executed whenever the criteriaFind method yields (or is forced to yield).

Andrew: The problem here is an assumption about what might be required in the future. Now if a later change was to allow partial matches on fields, then perhaps we could do it by creating an overloaded criteriaFind within the Data class itself. Why does it have to be in an extended class?
Patrick: No comment here except that this a violation of OCP.

Sure.
Although there are people who suggest that adding an overloaded method does not violate the Open-Closed Principle: the original code has not changed.
You can see this in effect when Sun make additions to a published API. For example, the JLabel.setDisplayedMnemonicIndex method has been added to existing to the existing JLabel class in version 1.4 of the JDK.

You discuss breaking clients. But by extending an existing class you will be breaking the existing contract and hence break clients which depended on that contract.

I'm not sure I follow. If I extended an interface then I could break existing clients. But if I just add a new method to an existing class, even if it overloads an existing method, I should not break any existing clients.

Andrew: What happens if there are existing applications that are using Data class? We have not been told that there are no other applications - there could be a reporting application and a bulk data entry program already written. Since we have been given a database that already contains records, it is quite likely that there is at least one other application out there than can access the database, possibly through the use of the Data class. You will have just broken that other application.
Patrick: .. Not if the contract on Data is loosening as explained just now.

If all you are doing is loosening access to methods and variables within Data, then I agree - you have not broken Data.
But you originally suggested that we should "declare criteriaFind() an abstract method". Which does more than just loosen Data - it actually forces Data to become an abstract class.

You explain that the requirements specifies that the Data class is already fully functional and that making it abstract prevents it from being fully funtional. Why then does is it also mention that we can implement criteriaFind() by modification(in the Data class) or by extension(in sublasses)?

You do not have to declare criteriaFind to be abstract in Data if you want to implement it in a class that extends Data.
I don't have a problem with criteriaFind being developed in a class that extends Data - that is your choice. What I do have a problem with was the suggestion that criteriaFind should be an abstract method in Data.
I am enjoying this discussion, and I think it is valuable, so please come back with any further comments.
Regards, Andrew

[Philippe Maquet]

Umm ... it's as fascinating as a Wimbledon final, and alike I ask myself : "How those guys do that ?". And it's tie-break ! Great !
Phil.