File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes Developer Certification (SCJD/OCMJD) and the fly likes Hardcoding field names Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Soft Skills this week in the Jobs Discussion forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "Hardcoding field names" Watch "Hardcoding field names" New topic
Author

Hardcoding field names

Lasse Koskela
author
Sheriff

Joined: Jan 23, 2002
Posts: 11962
    
    5
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.


Author of Test Driven (2007) and Effective Unit Testing (2013) [Blog] [HowToAskQuestionsOnJavaRanch]
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
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 ]

Java Regular Expressions
Pete Lyons
Ranch Hand

Joined: Aug 18, 2002
Posts: 109
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.
John Sinues
Ranch Hand

Joined: Feb 21, 2000
Posts: 52
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
Mark Spritzler
ranger
Sheriff

Joined: Feb 05, 2001
Posts: 17260
    
    6

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


Perfect World Programming, LLC - Two Laptop Bag - Tube Organizer
How to Ask Questions the Smart Way FAQ
Max Habibi
town drunk
( and author)
Sheriff

Joined: Jun 27, 2002
Posts: 4118
I agree with Mark. I don't see any reason to take an unnecessary risk with FileIO(property files), or by introducing new constants, etc. IMO, use the material that's already there.
HTH,
M, author
The Sun Certified Java Developer Exam with J2SE 1.4
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Hardcoding field names