Java Bean, Constructor, Abstract class

[Alana Sparx]

Hello

Bit od a design question here.
I have an abstract class, called Person.
A person has firstName, middleName, surname, all populated within the abstract class. Abstract methods get data of birth (allowing for subclass specific date formats etc)

Person is expected to be sublassed to Applicants, Customers, Employees etc, all providing own concrete implementations.

Is there any benefit to 'Person' being coded as a Java Bean (ie can abstract classes be Java Beans and benefit from reflection, introspection etc), or can I provide a constructor that populates the 'name' attributes?

Many thanks
As

[Jeff Albertson]

In settings where Java Beans (or POJOs) are used, for example Hibernate, it is common that some of the classes extend abstract classes. If you want your context to be able to manipulate a particular attribute defined in the abstract class, the corresponding methods of the abstract class should follow the Java Bean formula:

public String getFirstName()
public void setFirstName(String firstName)

These methods can be either abstract or not -- it doesn't matter. (Hibernate can even work with private methods, but that's another story.) As far as the constructors for the abstract class, there are no restrictions, since its only the constructors of the concrete subclasses that will be called by the context using the Java Beans.

[Chengwei Lee]

Hi Alana,

If you're going to have a constructor to take in a parameter, I'd suggest that you create a default argument-less constructor as well. Your JavaBean could be modeling a table or a few tables in the DMBS. You could use it to implement the Transfer (Value) Object pattern.

If you implemented the equals & hashCode methods, you could meaningfully compare the JavaBeans, sort them in collections. If you implemented toString method meaningfully, they could come in handy for logging purposes.

Hope these benefits help.

[Ernest Friedman-Hill]

Originally posted by Chengwei Lee:

If you're going to have a constructor to take in a parameter, I'd suggest that you create a default argument-less constructor as well. .

Did you read Jeff's (quite insightful) post? She's asking about an abstract class. There's no need for it to have a default constructor -- only the subclasses would need them. The constructors of this base class are irrelevant to the JavaBeans status of the subclasses.

[Alana Sparx]

Thanks all.

So, provide the setter/getter methods to allow for benefits of Java Bean behaviour. Constructor provision in the abstract class isn't an issue.

Although, there's something odd about an abstract class having a constructor. It's abstact, you can't construct one, if you see what I mean....

[Jeff Albertson]

Originally posted by Alana Sparx:
Although, there's something odd about an abstract class having a constructor. It's abstact, you can't construct one, if you see what I mean....

Nothing odd about, except for the name -- maybe it should be called an initialiser. Constructors can initialise instance fields and abstract classes often have instance fields (common data that has moved up the hierarchy). So it makes sense that you may want to pass data to a constructor so that it can use it to initialize its instance fields, and this remains a sensible thing to do, whether or not the class in question is abstract. Now attempting to write "new AbtsractClass(...)" -- that's a different matter!

[Henry Wong]

Although, there's something odd about an abstract class having a constructor. It's abstact, you can't construct one, if you see what I mean....

There is nothing odd about having a contructor in an abstract class. The constructor is to be used by the subclasses.

In any case, I guess you can make the constructor protected.

Henry

[Stan James]

I thought the original question was, as long as I'm making a Person class is there any reason to make it follow JavaBean conventions? Jeff went a good direction with "If you want your context to be able to manipulate a particular attribute..." but we kind of lost that big IF. The answer is going to depend on the architectural context of how the object is used.

If you build a generic framework to serialize a Person to XML you could surely benefit from JavaBean reflection or introspection. If you build a traditional rich domain object model it's better to have Person keep its data as private as possible and making a JavaBean is not a good idea. For architectures in between, the answers are less clear.

Alana, can you describe your application a little more ... how these objects will be used? What's your basic architecture?