Ken Sloan
Posts: 35
Nickname: sloan
Registered: Sep, 2003
|
|
Re: Java program structure
|
Posted: Mar 9, 2005 10:15 AM
|
|
First, a disclaimer. I'm somewhat self-taught via lots of time reading tutorials and forums (this one, in particular, is the best I've found) so a lot of what I'm going to put forward is only my opinion. In my defense, though, I will say that I do have a lot of background in non-Java programming and object modeling using UML. So, a lot of what I'm going to throw out here, I believe, is just generally accepted good practice. I will, however, defer to the rest of the forum--they generally are more experienced than I.
My industry is vacation rental property so the business objects I deal with are things like Property, PropertyOwner, Reservation, etc.
My classes are directly derived from my business objects, so I have a java class called Property, for instance, which has all the relevant Property attributes and methods (getPropertyName(), deleteProperty(), etc.) along with any methods which use SQL to reference the Property table in my database. I use Swing components to provide end users with access to these objects. So if an end user needs to change the Property address, they pull up a Property JFrame, the JFrame instantiates a Property object, which in turn gets its data from the database and makes it available to the JFrame for display. The user does their thing, hits the 'Save' button and the JFrame scrapes the data from it's text fields, calls setter functions from the previously-instantiated Property object, and then asks the Property object to save itself to the database. The Property object has it's own methods to edit the data and determine whether to call an insert or an update method.
While my classes are derived from my business objects, my packages are more broadly based. I have one for "Reservation Management", which includes Property, Reservation, etc.; then another one for "Financials", which has classes like ReservationPayment, Expense, OwnerPayment, etc. Also, all my packages have sub-packages called UI, which has the various Swing components such as the one I described above. I also have my own "util" package for things like date formatters, string formatters, JDBC stuff, etc.--tools I had to write that are not specific to a business area.
I don't know if this is how others do it (in fact, I'm really interested in seeing what some of the other responses are) but it works for me.
I would strongly recommend that you spend a little time learning object modeling and UML. It makes it much easier (for me, anyway) to first define the business requirements in terms of business objects, then use Java to implement those objects.
|
|
Previous Topic
