aspose file tools*
The moose likes Beginning Java and the fly likes Java Bean, Constructor, Abstract class Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Java Bean, Constructor, Abstract class" Watch "Java Bean, Constructor, Abstract class" New topic
Author

Java Bean, Constructor, Abstract class

Alana Sparx
Ranch Hand

Joined: Feb 14, 2006
Posts: 121
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
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
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.


There is no emoticon for what I am feeling!
Chengwei Lee
Ranch Hand

Joined: Apr 02, 2004
Posts: 884
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.


SCJP 1.4 * SCWCD 1.4 * SCBCD 1.3 * SCJA 1.0 * TOGAF 8
Ernest Friedman-Hill
author and iconoclast
Marshal

Joined: Jul 08, 2003
Posts: 24187
    
  34

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.


[Jess in Action][AskingGoodQuestions]
Alana Sparx
Ranch Hand

Joined: Feb 14, 2006
Posts: 121
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
Ranch Hand

Joined: Sep 16, 2005
Posts: 1780
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
author
Sheriff

Joined: Sep 28, 2004
Posts: 18896
    
  40

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


Books: Java Threads, 3rd Edition, Jini in a Nutshell, and Java Gems (contributor)
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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?


A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Java Bean, Constructor, Abstract class