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 B&S : reason for Contractor/Record class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of EJB 3 in Action this week in the EJB and other Java EE Technologies forum!
JavaRanch » Java Forums » Certification » Developer Certification (SCJD/OCMJD)
Bookmark "B&S : reason for Contractor/Record class" Watch "B&S : reason for Contractor/Record class" New topic
Author

B&S : reason for Contractor/Record class

David Fishman
Greenhorn

Joined: Dec 28, 2003
Posts: 18
Hi all,

I have done some searcing on the reasons for wrapping the database strings (which the data layer has to use anyway according to Sun's DB interface) in a Contractor (or Record) class. Here is what I found so far, but I still can't justify using such classes for my design, considering I would really like to keep things as simple as possible.

Caching : which I consider out of scope
Sorting (providing comparators etc) : the word sort is never mentioned in Sun's instructions
Gui development (tableModel) : this one actually came close to a convincing argument, but then it seems to me that not much more is usually done here other than "conversion" of strings in the wrapper class to strings in the gui display
Future extendability : yes this makes sense as well, but considering the above it seems that dealing with strings now and adding the wrappers later would not be a huge task if the coding is kept relatively "clean" (which it should be for the General Considerations marks among other things)

Now I did introduce a separate MetaData class, but to me the main idea there is to separate functionality rather than form. On the other hand would it look "weird" to have a MetaData but not a Contractor class ?
Also it looks like many have introduced those wrapper classes - am I missing something here ?
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
David,

Whether or not to implement a record class is simply a design decision. There is no right or wrong answer. Some people like the object-orientedness of implementing one... while others like to keep it as simple as possible to limit the number of places you could lose points.

There are many issues such as these. Record class vs no record class. Cache or direct read. Locking strategies. And many more. The point isn't to find the right answer - because there isn't one. The point is instead to see how well you manage making these decisions.

Whatever you decide, just be sure to document it in your choices.txt and you will be fine.


“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: B&S : reason for Contractor/Record class
 
Similar Threads
NX: [UrlyBird 1.3.1] how flexible with the data format should we be?
About the suncertify.properties file
NX: File Consistency
Reading Record by Rec Number
NX:Contractors: Structure of package