Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > To pull up or not

Reply
Thread Tools

To pull up or not

 
 
-
Guest
Posts: n/a
 
      08-18-2005
For classes A, B, C.... that are not related to each other in any way,
why do most people prefer to put

addPropertyChangeListener(...
removePropertyChangeListener(...

in all classes rather than have them placed in common base class and
have A, B, C... extends it?
 
Reply With Quote
 
 
 
 
Jeff Schwab
Guest
Posts: n/a
 
      08-18-2005
- wrote:
> For classes A, B, C.... that are not related to each other in any way,
> why do most people prefer to put
>
> addPropertyChangeListener(...
> removePropertyChangeListener(...
>
> in all classes rather than have them placed in common base class and
> have A, B, C... extends it?


If you are suggesting a base class defining these methods for purposes
of implementation inheritance, it is generally not worthwhile. Defining
these methods separately in each class is not difficult, and is more
flexible. The class Observable does fill a similar role to your
hypothetical base, though.

Classes may extend an interface specifying add/remove<EventType>Listener
methods, but I have not seen much need for such an interface except in
certain types of frameworks.
 
Reply With Quote
 
 
 
 
jan V
Guest
Posts: n/a
 
      08-18-2005
> If you are suggesting a base class defining these methods for purposes
> of implementation inheritance, it is generally not worthwhile. Defining
> these methods separately in each class is not difficult, and is more
> flexible.


I agree with this, but **strictly** for classes that truly have absolutely
nothing in common.

For classes that do have something in common ("They're all xxxx") code
duplication is a major, major evil in company-wide code bases. Having
identical pieces of code in multiple classes often leads over time to
(because of this "it's more flexible" belief) classes with *nearly*
identical pieces of code, which is a maintenance nightmare.

In practice (in medium-sized, and definitely large, projects), these
situations often get out of hand and you end up with dozens and dozens of
similar classes which should have had a common (abstract) superclass, or
even a super hierarchy. If left to breed unchecked leads to levels of code
entropy and inertia that are so severe that noboy is willing to bite the
bullet and perform the tedious and massive refactoring job to bring order to
the mess.


 
Reply With Quote
 
Jeff Schwab
Guest
Posts: n/a
 
      08-18-2005
jan V wrote:
>>If you are suggesting a base class defining these methods for purposes
>>of implementation inheritance, it is generally not worthwhile. Defining
>>these methods separately in each class is not difficult, and is more
>>flexible.

>
>
> I agree with this, but **strictly** for classes that truly have absolutely
> nothing in common.
>
> For classes that do have something in common ("They're all xxxx") code
> duplication is a major, major evil in company-wide code bases. Having
> identical pieces of code in multiple classes often leads over time to
> (because of this "it's more flexible" belief) classes with *nearly*
> identical pieces of code, which is a maintenance nightmare.
>
> In practice (in medium-sized, and definitely large, projects), these
> situations often get out of hand and you end up with dozens and dozens of
> similar classes which should have had a common (abstract) superclass, or
> even a super hierarchy. If left to breed unchecked leads to levels of code
> entropy and inertia that are so severe that noboy is willing to bite the
> bullet and perform the tedious and massive refactoring job to bring order to
> the mess.



I think the general solution is to encapsulate shared functionality in
special-purpose objects, and for other objects needing the functionality
to contain the special-purpose objects (rather than inherit from them).
The only duplicated code then becomes the wrapper methods, e.g:

public class MyClass {
private ObjectThatDoesX otdx = new ObjectThatDoesX();

public void doX() {
otdx.doX();
}
}

What bothers me most about implementation inheritance in Java is that
there is no private inheritance (as in C++), so there is no clear way to
distinguish implementation inheritance from interface inheritance. IOW,
if you have multiple classes inheriting from ObjectThatDoesX for
implementation reasons, it may be tempting to start handling the
subclasses using references of type ObjectThatDoesX. Then, when the
implementation of one of the subclasses needs to change and
ObjectThatDoesX is no longer required as a superclass, all of those
references will break.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
weak pull up and pull down krithiga81@yahoo.com VHDL 2 06-28-2006 02:18 PM
NEWBIE - Learning how to pull SQL not in Grid or Details view Phillip Vong ASP .Net 1 02-24-2006 08:51 PM
About to pull my hair out!! jpwilliamson@gmail.com Wireless Networking 1 09-03-2005 12:09 PM
Firefox hangs using pull-down menus Jim Lahue Firefox 1 06-07-2005 03:47 PM
Pull the wall plug or not? texan.usenet@texasremovethisbit.usa.com NZ Computing 8 09-08-2004 02:52 PM



Advertisments