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.
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 ]
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.