This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
So, what do you guys think of hardcoding the database field names like "Origin airport"? I get the creeps everytime I need to get the value of a certain field. The DataInfo class doesn't really help avoiding hardcoding, so I thought of creating a wrapper/composite class for the DataInfo (something like "suncertify.db.Flight"). Comments? Btw, Max, I got your book and I have to say it's pretty darn close to what a certification study book should be like.
Glad to hear that the book is working out for you. They make wonderful Christmas presents . As to your question: I suggest that you hard code them in an interface, and refer to them from that interface(aren't they already in the Records interface?). Along the same lines, make sure that when you extract the names from the JTable, you don't use the column name of the table, as a Jtable's default behavior is to allow the use to move the column. All best, M, author The Sun Certified Java Developer Exam with J2SE 1.4 [ October 09, 2002: Message edited by: Max Habibi ]
I created a business class called suncertify.Flight. (The key is that it's NOT db specific, so it shouldn't go in the db package). Although I'm uncertain what Sun thinks, so remember that this is just my humble opinion, I feel that such a class is an extremely clear and obvious necessity, and using DataInfo instead of it would be a very non-standard OOP technique. Although it can have little if any business logic for this part of the assignment, you will eventually want to put business logic and validation code in there as the program grows. As to hard coding the names at the UI level, I'm all for it. As a general rule automtically or dynamically generated user interfaces (which I have worked with extensively), come out clumsy and awkward, and occasionally downright awful. Now does this mean you should sprinkle your code with string literals and reference things by row index in a JTable, certainly not. But, I feel you should hard code the labels for the table columns as well as the order they are presented in to be common sense and not dependent on what order they are written to the db.db file. For example, my table labels the columns "From" and "To" in that order by design, and that's how it's going to stay even if the persistence mechanism or file format changes, and since I populate them by calling flight.getOriginAirportCode() and flight.getDestinationAirportCode(), I'm not relying on array indexes and other hard to read and maintain silliness.
Another alternative would be to use the java.util.Properties class and store these types of configuration parameters in a file. I utilized a properties file for my conversion program (I have one of the older projects that requires a conversion utility), the server code, and the client code to store field names, labels, indices, client GUI height, width, and other information that could be easily changed without requiring recompilation. - John
I really had no problem getting data that I needed form fields that I wanted just using Data, DataInfo, and FieldInfo classes. While a wrapper class could make it easier for you to finally get that data, you would be adding a redundancy, and might make it tougher for a junior programmer to maintain, which is one of the requirements. But it is still you choice. Mark