It's harder than I though to stick with OO

[Marc Twain]

This might be modelling 101 but I'll give it a go: I'm trying to have
a JavaBean that maps one or more table in a DB.

So I create a 'User' bean. The no arg Constructor is used to create a
brand new user with default properties. Another constructor takes a
Primary key as an argument to create a new user from the database.

Then I add 'save()' and 'update()' methods. So far so good. (I guess)

The problem is, if I add a delete() method, it means I have to
instantiate a user object before calling delete() on itself. Doesn't
make much sense to me!

And finally all goes to hell when I end up having to list a bunch of
users... I don't even know where to place that listUsers() method. As
a static method of the User class?

Does anyone have faced the same problems or am I just approaching the
issue the wrong way? I have 5 java books on J2EE but none of them
cover those modelling issues.

Any idea?

TIA,

AJ

 

[Anton Spaans]

The 'save()' and 'update()' are operation on the *row*, on the User
*Object*.

What you could do is to make creation/deletion, which are operations on the
*table*, *static* methods.

public static User newUser()
{
return new User();
}

and do this for all the necessary constructors, which you make private or
protected.

Then, to delete a row:
public static void deleteUser(User pUser)
{
....
remove pUser.getPrimKey() from table.
}
-- Anton.

 

[David Robbins]

This might be modelling 101 but I'll give it a go: I'm trying to have
a JavaBean that maps one or more table in a DB.

So I create a 'User' bean. The no arg Constructor is used to create a
brand new user with default properties. Another constructor takes a
Primary key as an argument to create a new user from the database.

Then I add 'save()' and 'update()' methods. So far so good. (I guess)

The problem is, if I add a delete() method, it means I have to
instantiate a user object before calling delete() on itself. Doesn't
make much sense to me!

And finally all goes to hell when I end up having to list a bunch of
users... I don't even know where to place that listUsers() method. As
a static method of the User class?

Does anyone have faced the same problems or am I just approaching the
issue the wrong way? I have 5 java books on J2EE but none of them
cover those modelling issues.

Any idea?

TIA,

AJ

start with a good book on basic object oriented design and programming.

but basically you decide what information you have to have and the
relationships between the information and the operation that need to be done
on that information. then you divide up the information and operations into
classes such that each class is contained within itself. this operation
frequently requires a couple iterations. warning flags that you have not
properly grouped the information and operations into the right classes are
questions like what you have about how to make a list of users, and why
delete() doesn't make sense.... those point to errors in dividing up the
information and what needs to be done with it.

I would just quickly say that you need at least 3 different classes...
1. a database user class that handles reading, writing, deleting and other
things that go on with the database.
2. a user class that holds the information about a single user. it might
call the database user class to get or save it's internal information, or
that may be done by some other class that creates users.
3. a user list class that contains a list of users. it would provide things
like the count of the number of users, iterators to go through a list, maybe
searches for types of users, ways to add and remove users from the list,
etc...

and outside of all that you would need some other way to create each of
those types of things and make them actually do something. a gui with
controls to create and enter data for users, displays for listing
information, etc... all outside of the individual classes that hold and
operate on the information.

packaging things into a bean is another problem and depends on what you need
to provide as services to all the other beans in the world... a bean could
be something like a 'user management' bean that encapsulates all of the
above including the gui, or it could be just a single class... this type of
design decision would have to be made when you know who wants to use your
bean and what they need to do.

 

[Christophe Vanfleteren]

This might be modelling 101 but I'll give it a go: I'm trying to have
a JavaBean that maps one or more table in a DB.

So I create a 'User' bean. The no arg Constructor is used to create a
brand new user with default properties. Another constructor takes a
Primary key as an argument to create a new user from the database.

Then I add 'save()' and 'update()' methods. So far so good. (I guess)

The problem is, if I add a delete() method, it means I have to
instantiate a user object before calling delete() on itself. Doesn't
make much sense to me!

And finally all goes to hell when I end up having to list a bunch of
users... I don't even know where to place that listUsers() method. As
a static method of the User class?

Does anyone have faced the same problems or am I just approaching the
issue the wrong way? I have 5 java books on J2EE but none of them
cover those modelling issues.

Any idea?

TIA,

AJ

You might want to look into the DAO pattern.
http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html