Newbie java/OO question 4

[p3t3]

Hi,

I have a basic question about style.

When writing a new object is it common to give the object a load/save method, which transfers a whole instance of the object to/from the database, or, would it be more usale to update each property individualy if/when they change?

Thanks in advance, have googled but maybe my search terms are off...

 

[sedj]

Depends on your usuage of you class - if a design makes sense, then use it ...

Maybe you could write a class that loads/saves the object state into a db, and then if another objects needs to do this action, then you could extend the class, and so use its methods.

 

[p3t3]

Thanks, I think Ive got to go back to reading a little more about this subject. As am just really starting with JAVA Im quite unsure how much to abstract out, especialy at the data layer. Ive just got hold of Thinking in Java, but can anyone recommend some good examples (code or books), of how to handle data in real world situations?

http://www.freesome.com

Digital Soma

 

[sedj]

"Learning Java" at

http://www.oreilly.com

is a fantastic beginners book, with some excellant ideas for real-world app design. Also "Programming Java Servlets" is good (by same pulisher).

 

[hologram]

Normally you would save a complete object or even more objects at once. If you change your data via a Gui, then you could have an "OK" and a "Cancel" button and save everything that is on the screen in one go. When using a relational database you would also put this under commitment control (so that ALL the files get updated, or none at all).

 

[p3t3]

Thanks, hologram.

Could you just advise me on how abstract you make your object save class. I.E do you tend to have, as sedj suggests, a class which loads/saves any object , or does each class have its own custome .load() .save() methods?

At present I have a DB class which has methods for INSERT UPDATE and DELETE, and each object has it's own load/save/saveNew method, which calls the appropiate DB method with a SQL string. Then, obviously, a top level object calls it's child objects load/save mothods from within its own load/save method.

Am I barking at the correct tree here?

 

[hologram]

I am a traditional programmer, not an OO programmer so... But this is what I was thinking of :

- Your use a DB class is OK.

- Let your classes that need to be saved, implement an interface ("saveAble&quot with "load()", "save()", "saveNew()" methods.
- Implement those methods in these classes, but delegate to a class (a seperate class per class to be saved) that builds the SQL string and delegates further to your DB class. [ Then you don't cluther your original classes with SQL stuff. You could switch to JDO or EJB or OO-database ... without changing your original class. ].
- The "delegateClasses" CAN implement an interface and CAN extend from a class if needed.
- I would NOT extend your original classes from a common "super" class with SQL or other "save" stuff.

But I repeat :
I am a traditional programmer, not an OO programmer so...

 

[palbano]

One of the best sources for understanding object oriented design is to begin reading about Software Patterns.

The original book is still published (Design Patterns
Elements of Reusable Object-Oriented Software ISBN 0-201-63361-2)and there also is one specific to Java development. Try starting at the Portland Pattern Repository:

http://c2.com/ppr/

In Java and J2EE there are specific patterns dealing with database access like Fastlane Reader

-pete

 

[p3t3]

Yes, I had been holding off reading about patterns until I had a good grasp of the basic language, but I think it may be time now, before I repeat all of the errors of the past!!

Thanks...