To pull up or not

Discussion in 'Java' started by -, Aug 18, 2005.

  1. -

    - Guest

    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?
    -, Aug 18, 2005
    #1
    1. Advertising

  2. -

    Jeff Schwab Guest

    - 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.
    Jeff Schwab, Aug 18, 2005
    #2
    1. Advertising

  3. -

    jan V Guest

    > 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.
    jan V, Aug 18, 2005
    #3
  4. -

    Jeff Schwab Guest

    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.
    Jeff Schwab, Aug 18, 2005
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Hazzard
    Replies:
    1
    Views:
    466
    Hazzard
    Apr 2, 2004
  2. Tommy

    Pull model implement on website

    Tommy, Jun 28, 2004, in forum: ASP .Net
    Replies:
    3
    Views:
    366
    Eliyahu Goldin
    Jun 28, 2004
  3. David Lozzi
    Replies:
    1
    Views:
    434
    Lucas Tam
    Aug 9, 2004
  4. Phillip Vong
    Replies:
    1
    Views:
    350
    Paul Zanbaka
    Feb 24, 2006
  5. Replies:
    2
    Views:
    2,154
    Mike Treseler
    Jun 28, 2006
Loading...

Share This Page