Managing access to hierarchies

[villo]

Hi everyone,

this shouldn't really be a matter of patterns but that's it, here it is anyway...

Basically I have the following users hierarchy:

pubilc class User{
String username;
String passwd;
//...other attributes common to all the types
}

public class Customer extends User{
...
}
public class Guest extends User{
...
}

Persisted with OJB.

the point is that i'm trying to build an EJB to give an as much unified as possible interface to these VOs; the problem is that until now I didn't come up with anything that satisfies me.
I don't know if it's better to add an attribute like User.type, so that I can handle the subclasses in a sort of facade.

The point is that at least with the getters I am forced to have

getUser()
getCustomer()
getGuest()

since they must return the proper type.

I guess this is a common issue, so, any idea?!

thanks all,
villo

[jamesstrachan]

Villo,

A cursory look at OJB suggests that it should successfully load and store objects of the different classes.

My approach to this problem would be to create an abstract super class above all the actual user classes.

so you have a hierarchy :-

public abstract class AbstractUser {
...
}

public class InternalUser extends AbstractUser {
...
}

public class Customer extends AbstractUser {
...
}

You can then have a single getter method and setter method using the abstract class as follows :-

public AbstractUser getAbstractUserValueObject( String username ) {
...
}

and test for what you have received on return either with instanceof :-

AbstractUser aUser = remote.getAbstractUserValueObject( String username );
if ( aUser instanceof Customer ) {
...
}

or by having an abstract method

public String getUserType()

in the abstract class which is implemented to return a different code for each concrete class.

It would be a good idea to have a set of finder methods that return only instances of each concrete class.

I would also be a bit worried that you may get clashes of usernames between the various sets of users. You may avoid this if you have a fairly small user population and can prevent reuse of the same name.

I have an example of this approach. It's too large to post here but I could zip it up and e-mail it to you.

James