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

Newbie Question about Java Beans

Shivaji Marathe
Ranch Hand

Joined: Jan 11, 2002
Posts: 203
While reading the chapter on Java Beans in the Core Java Vol 2, I noticed that the JComponent class also includes some of the methods of the java.beans.PropertyChangeSupport object.
Does this mean that the code for these methods exists in two places? Isn't this bad programming practice? Why would Sun do something like this?
Also, I noticed that the Jcomponent class has overloaded versions of the firePropertyChange method - one for each of the primitive types . These are public methods. The firePropertyChange method that takes object arguments is protected. What is the reasoning behind making this one protected while the others are public?
I'm not sure if this question is appropriate in the EJB forum, that's why I'm posting here.
Junilu Lacar
Bartender

Joined: Feb 26, 2001
Posts: 4757
    
    7

Originally posted by Shivaji Marathe:
Does this mean that the code for these methods exists in two places? Isn't this bad programming practice? Why would Sun do something like this?

Answering in reverse order:
3. It is highly unlikely that the kind of code you refer to would make its way into the standard classes.
2. Yes, duplication of code is bad programming practice. As the Pragmatic Programmers like to say: "Don't Repeat Yourself" (the DRY principle of pragmatic programming).
1. No, the code in the two methods are not duplicated. If you have the JDK installed, you probably have the source (look for src.jar) so go ahead and take a look. You'll see that Component "has a" PropertyChangeSupport and that the "duplicate" methods in Component actually delegate the actual work to the contained PropertyChangeSupport. This follows the "Favor Composition over Inheritance" OO Design Principle described in this document: http://www.research.umbc.edu/~tarr/cs491/lectures/OOPrinciples.pdf
HTH,
Junilu
[ March 01, 2002: Message edited by: Junilu Lacar ]

Junilu - [How to Ask Questions] [How to Answer Questions]
Wirianto Djunaidi
Ranch Hand

Joined: Mar 20, 2001
Posts: 210

To address the last question regarding public and protected method.
I believe it's because JComponent is high level class which
is expected to be extended by a lot of child classes.
The public method are mostly for primitive type, because
they are type-safe and pretty straight forward to override.
But I belive the designer made the Object type protected
for a purpose, that the user of the class or the child classes
can't just use them. It forced the child class to provide
public method that accept *specific* class, so you can
have method that accept Point or Color object instead
of just plain Object class.
I hope that make sense.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Newbie Question about Java Beans