• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Newbie Question about Java Beans

 
Ranch Hand
Posts: 203
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Sheriff
Posts: 17644
300
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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 ]
 
Ranch Hand
Posts: 218
VI Editor Ruby Ubuntu
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic