Too many if statements

[HS Thomas]

Hi and a happy New Year one and all.
With a view for future enhancements I decided to define a Table class and Locks class. So a context parameter determines which static variable is returned by their respective getInstance() methods.
As the number of Tables increases the number of if statements increases. I also associate getInstance methods with singletons which everyone agrees are a bad idea.
I think there's room for improvement here.
Perhaps Factory pattern would be better. This wouldn't get rid of the if statements but would not bring to mind the dreaded singletons. (Even though they are in effect singletons )

 
class Table {
static Data table1 = table1Instance;
static Data  table2 = table2Instance ;
Data tableInstance;
private  Table (String context) {
 if (context == type1Context) {
     tableInstance = table1Instance ;
}
 if (context == type2Context) {
     tableInstance = table2Instance ;
}
...
...
...
...
static syncnronized Data getTableInstance (String context) {
new Table(context);
return tableInstance;
} 
}
 

table1Context , table2Context etc are literals.

[Mark Spritzler]

Well I'll start out with the old, going beyond the requirements statement. One of the objectives in the assessors eyes is how well did the tester follow instructions and not go overboard on a design.
I will say that adding a Table class is a little extra that is not needed. Now you Lock class you can consider the LockManager class which has been discussed many times here as a decoupled way to added the locking that the instructions ask for, so it is not beyond the requirements.
Mark

[HS Thomas]

Hi Mark,
Point taken about the designing beyond the given requirements.
As far as the Table class is concerned I'd argue that this was added to cater for future requirements and is not an embellishment. This may be beyond the scope of the assignment but I hope I won't be marked down for catering for this. I'd accept that I would be marked down for not coding a very elegant solution. A series of if statements isn't very elegant. In fact, I'm not sure that the approach that each GUI view (context) approximates to a Table is correct. I know it's pretty short-sighted. GUI views require data from many sources.

I have implemented the Connection object per client approach , which creates a new LockManager class. My LockManager class contains an instance of the correct locks HashMap returned by the Locks class for the given context parameter .
comments welcome
regards

[HS Thomas]

I will say that adding a Table class is a little extra that is not needed.

Exactly so , considering I've been doing this assignment for about 9 months (not full time) having passed SCJP2 in 1999. I would like to wrap this up ASAP.

But I haven't reached the stage where I can say I am happy with this.
Having been given a file with flight info, available seats and not a single date in sight, didn't seem to allow for any useful functionality.
Guess what , I broke a rule or two and moved a piece of data around, but leaving the Data class intact , bar the deprecated methods. (Now I wouldn't want to confuse an assessor). I really hope if I document why I have done this, I don't get penalized.
I may lose points for a shoddy implementation, though.

[HS Thomas]

I broke a rule or two and moved a piece of data around,

By this I mean , I interpreted the given Available Seats as Seat Capacity and now maintain a separate persistent Count as the Available Seats on a flight for a given date.
I still use the Data class to access this Count.
Hence I was driven to think of multiple tables.
Wish I'd discovered this wonderful forum earlier, maybe I'd have sorted out the necessities before the nice to haves.
Just got rid of a rather rude Graemlin - it looked quite innocent when I copied him in
[ January 03, 2003: Message edited by: HS Thomas ]

[Mark Spritzler]

Does the requirements ask for dates? Does the data have date. Both are no. And I think a big reason or this might be to makes some parts easier so that the tester can focus on the more important aspects of the test.
Remember part of the score is General Consideration, and even though you might have an elegant solution for a Table class, not considering that all the information that you need is already provided for you in the Data class, that you will lose points in this area.
We will always say that in any choice you make you must defend yourself in the design.txt, so that almost any choice you make can work.
However, I still haven't heard a good argument for the Table class.
Mark

[HS Thomas]

OK Mark ,
I concede that Table class is overkill when we have been given the Data class, if it were trying to replace the Data class in any way.
But note the Table class I've implemented only returns the instance of the db file for the given context from the multiple db files that make up the Database.
Data class works with any and all db files.
Table class currently just specifies which db file so that the Data class knows which db file to open, write to , close etc. And also contains the different FieldInfo values for any new
db files. Note: The Data class already has a constructor which allows you to create new FieldInfo values.
I know that this isn't a winning argument and my implementation needs some re-work in places.
As far as dates are concerned, I have never booked a flight without specifying the date / week I want to travel on.
The instructions I have for the assignment re:
the suncertify.db file do say ,

you may not modify this file, but may move it if you wish

I haven't modified it, just re-interpreted the given Available Seats to mean Seat Capacity and stored Available Seats for a given Flight and Date in a different file , accessed by the same unchanged Data class.
The intention is to use the same GUI (or 90% of it) for the various functions as required and
use JavaBeans for Booking , viewing Flight Availability etc for a selected date.
The intention is also that a solution without implementing multiple tables/files and this one isn't going to be that far removed from each other , if re-use is designed in correctly.
I understand assessors have to turn around results in a month and don't have the time to peruse wildly differing solutions. God knows they are going to have to cope with wildly different GUI's as can be seen if you've ever tried to book flights online. But one thing they all do have is dates .
To be honest part of the reason I didn't tackle the assignment earlier was that I didn't understand Patterns and the absence of dates!
(And I hadn't discovered this forum) A datepicker was one of the first things I worked on for the GUI.
Cheers

[John Smith]

HS Thomas wrote:
...you may not modify this file, but may move it if you wish..
I haven't modified it, just re-interpreted the given Available Seats to mean Seat Capacity and stored Available Seats for a given Flight and Date in a different file , accessed by the same unchanged Data class.

I think you misinterpreted the instructions. When they say you cannot modify db.db, all they mean is that you should include the original db.db in your submission. By all means, do modify the original db.db (after you back it up), how else are you going to test the booking and multithreading?
There is no need whatsoever to create any different files, as you seem to suggest.
Eugene.
[ January 03, 2003: Message edited by: Eugene Kononov ]

[HS Thomas]

Hi Eugene,
In the given assignment , how else would you allow for

if another table is added to the database

as discussed here
I've just taken it one step further and re-used the Data class to create another table/file .
I took the given db.db file to be just a Flight
Schedule i.e Flight A001 runs on Thursday at 21:00 hrs each week.
When it comes to Booking a Flight the user needs to specify a date , and the system checks the Available Seats of the Flight on that date stored on another table / file.

[John Smith]

I've just taken it one step further and re-used the Data class to create another table/file

You don't need to create any table/files. All you have to do is to have the server create a connection object that has an instance of Data. That instance of Data should be created using constructor Data(String dbname) where dbname is your file name. That's all there is to it.
Eugene.

[HS Thomas]

Hi Eugene and Mark,
I think we are talking about the same thing.
Do you agree ?
I haven't included any code that creates a file like :

 new File(dbname) 

The ConnectionFactoryImpl class has

 synchronized public RemoteFlights getConnection(String context) throws Exception,RemoteException
    { 
  
        return new Connection().getInstance(context);
        
    }  

The method in Connection is

     public RemoteFlights getInstance(String context) throws IOException, Exception {
         data = new FlightsImpl(new FlightsInstance().getFlightsInstance(context),this);
         return data ;  

RemoteFlights is the RemoteInterface
I do have an AbstractFactory layer between the above and the Table class . this means you just can't connect and create any file. The system has to expect it . Good for security ! And keeps me in a job !
The Table class is essentially

    
         if (af == null) 
             
            {  af  = new FlightsAvailable( homedir + File.separator + AF_DBNAME ); } 
         // File doesn't already exist so call the constructor with the relevant FieldInfo values
         } catch (IOException e) { if (af == null)
         
            {  af  = new FlightsAvailable(homedir + File.separator + AF_DBNAME, af_fields ); } 
     
         } 
 

Where af_fields defines the new FieldInfo values .
OK , I made Data abstract and extended it in the
FlightsAvailable class, the FlightsBooked,FlightsCatalogue classes.
In all these blurbs

context

is essentially a table name. Though I'm not too happy with this as GUI views can get data from many sources.
Each table name defined in the Table class is a Singleton.
Do ask if I need to clarify or defend anything .
Also , do you have an issue with the way I've incorporated dates, Eugene?
Thanks
[ January 04, 2003: Message edited by: HS Thomas ]
[ January 04, 2003: Message edited by: HS Thomas ]
[ January 04, 2003: Message edited by: HS Thomas ]

[HS Thomas]

Hi Mark and Eugene,
I have taken your advice and decided to Keep It Simple. Much happier doing so since I discovered the the 1 ConnectionFactory per table name option.
So out goes Table class ! And all those if statements centred around the table instances !
Out go my extra db files and extended classes , but my date picker stays as just a Calendar on the GUI.
I think I'm still left with an infrastructure that allows for table extensibility . I'm happy !

[HS Thomas]

Oh! I forgot ! Thanks.

[Mark Spritzler]

Thank you HS. It is good to see you seeing the light.
Simpler always seems to end up being the best solution, it ends up being easier to code and maintain.
Mark