Win a copy of Re-engineering Legacy Software this week in the Refactoring forum
or Docker in Action in the Cloud/Virtualization forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Hardcoding field names

 
Lasse Koskela
author
Sheriff
Posts: 11962
5
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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 ]
 
Pete Lyons
Ranch Hand
Posts: 109
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 52
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 17278
6
IntelliJ IDE Mac Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
Max Habibi
town drunk
( and author)
Sheriff
Posts: 4118
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic