Ensuring a method is overridden

Discussion in 'Java' started by Mike Amling, Sep 8, 2009.

  1. Mike Amling

    Mike Amling Guest

    A certain class is used 80% of the time as is, and is extended 20% of
    the time. I want to ensure that each subclass overrides a certain
    method. The only way I can think of to do this is to put code in the
    base class's constructors, and when the class being constructed is not
    the base class, check that getDeclaredMethod does not throw a
    NoSuchMethodException.
    Does anyone know of a more efficient way? At compile time, maybe?

    --Mike Amling
    Mike Amling, Sep 8, 2009
    #1
    1. Advertising

  2. On Tue, 08 Sep 2009 00:20:32 -0400, Mike Amling <> wrote:

    >
    > A certain class is used 80% of the time as is, and is extended 20% of
    > the time. I want to ensure that each subclass overrides a certain
    > method. The only way I can think of to do this is to put code in the
    > base class's constructors, and when the class being constructed is not
    > the base class, check that getDeclaredMethod does not throw a
    > NoSuchMethodException.
    > Does anyone know of a more efficient way? At compile time, maybe?


    Why not just declare the method abstract in the base class?
    Or am I misunderstanding something?

    --
    Morris Keesan --
    Morris Keesan, Sep 8, 2009
    #2
    1. Advertising

  3. Mike Amling

    markspace Guest

    Mike Amling wrote:
    >
    > A certain class is used 80% of the time as is, and is extended 20% of
    > the time. I want to ensure that each subclass overrides a certain
    > method. The only way I can think of to do this is to put code in the
    > base class's constructors, and when the class being constructed is not
    > the base class, check that getDeclaredMethod does not throw a
    > NoSuchMethodException.
    > Does anyone know of a more efficient way? At compile time, maybe?
    >
    > --Mike Amling



    I agree that "abstract" is the way to go here. Make a base class with
    that method abstract. Then make a new derived class that is final and
    that is intended to be used 80% of the time, like the main class is now.

    For the other 20% of the time, since the new class is final, programmers
    will be forced to use the base class, which has one method abstract that
    must be overridden.
    markspace, Sep 8, 2009
    #3
  4. Mike Amling

    Roedy Green Guest

    On Mon, 07 Sep 2009 23:20:32 -0500, Mike Amling <>
    wrote, quoted or indirectly quoted someone who said :

    > A certain class is used 80% of the time as is, and is extended 20% of
    >the time. I want to ensure that each subclass overrides a certain
    >method. The only way I can think of to do this is to put code in the
    >base class's constructors, and when the class being constructed is not
    >the base class, check that getDeclaredMethod does not throw a
    >NoSuchMethodException.
    > Does anyone know of a more efficient way? At compile time, maybe?


    The other way out of this is to put an assert in the method that must
    be overridden.

    It could use this.class to figure out if it is working with a base
    class or an extension. If they have overridden, the assertion won't be
    there.

    To get fancy you want to make it ok if they call super. You could look
    at the stack. See http://mindprod.com/jgloss/trace.html

    Others might have better ways of doing this with a run time check.

    These is a similar problem that I suggested fixing in Bali. See
    http://mindprod.com/jgloss/bali.html

    If you write a method to override, but get the signature or spelling a
    tad off, it WON'T override the base method, and the compiler won't
    tell you. I wanted to use an explicit override keyword to make the
    compiler ensure the definition indeed overrode something in the base
    class. There is now an annotation for that.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "I mean, source code in files; how quaint, how seventies!"
    ~ Kent Beck (born: 1961 age: 48), evangelist for extreme programming.
    Roedy Green, Sep 8, 2009
    #4
  5. Mike Amling

    Lew Guest

    Roedy Green wrote:
    > On Mon, 07 Sep 2009 23:20:32 -0500, Mike Amling <>
    > wrote, quoted or indirectly quoted someone who said :
    >
    >> A certain class is used 80% of the time as is, and is extended 20% of
    >> the time. I want to ensure that each subclass overrides a certain
    >> method. The only way I can think of to do this is to put code in the
    >> base class's constructors, and when the class being constructed is not
    >> the base class, check that getDeclaredMethod does not throw a
    >> NoSuchMethodException.
    >> Does anyone know of a more efficient way? At compile time, maybe?

    >
    > The other way out of this is to put an assert in the method that must
    > be overridden.
    >
    > It could use this.class to figure out if it is working with a base
    > class or an extension. If they have overridden, the assertion won't be
    > there.
    >
    > To get fancy you want to make it ok if they call super. You could look
    > at the stack. See http://mindprod.com/jgloss/trace.html
    >
    > Others might have better ways of doing this with a run time check.


    Since the 'abstract' keyword works, and reflection is both messy and slow,
    eschew reflection.

    Any time you code an instance to figure out what class it is in order to
    decide which behavior to use, you've messed up. (To nitpickers: that's the
    first order of approximation.)

    (and the second)

    (...)

    You don't need a run-time check.

    --
    Lew
    Lew, Sep 8, 2009
    #5
  6. Mike Amling

    Mike Amling Guest

    Mike Amling wrote:
    >
    > A certain class is used 80% of the time as is, and is extended 20% of
    > the time. I want to ensure that each subclass overrides a certain
    > method. The only way I can think of to do this is to put code in the
    > base class's constructors, and when the class being constructed is not
    > the base class, check that getDeclaredMethod does not throw a
    > NoSuchMethodException.
    > Does anyone know of a more efficient way? At compile time, maybe?


    Thank you to all who responded. I presume you recommend some kind of
    proxy to ensure toString, equals, hashCode, etc. are overridden:

    abstract class Basso {
    protected abstract String abString();

    public final String toString() {
    return abString();
    }
    }

    final class Extenso extends Basso {
    public String abString() {
    return "whatever";
    }
    }

    --Mike Amling
    Mike Amling, Sep 8, 2009
    #6
  7. Mike Amling

    markspace Guest

    Mike Amling wrote:

    > Thank you to all who responded. I presume you recommend some kind of
    > proxy to ensure toString, equals, hashCode, etc. are overridden:



    That works, and I think I've seen it done. However, consider a code
    review instead. ;)
    markspace, Sep 8, 2009
    #7
  8. Mike Amling

    Lew Guest

    Mike Amling wrote:
    > I presume you recommend some kind of
    > proxy to ensure toString, equals, hashCode, etc. are overridden:
    >
    > abstract class Basso {
    >    protected abstract String abString();
    >
    >    public final String toString() {
    >      return abString();
    >    }
    >
    > }
    >
    > final class Extenso extends Basso {
    >    public String abString() {
    >      return "whatever";
    >    }
    >
    > }


    That's sort of a strange suite of methods to require overriding. It's
    already best practice to override toString, hashCode and equals,
    though not "etc.". (What other methods of Object do you contemplate
    overriding? Not much else makes sense to override.)

    The pattern you show is a common one - define an abstract base class
    with a public method that invokes abstract helper methods so that
    subclasses can provide the varying parts. Often the abstract methods
    are protected rather than public, since it's the wrapping method
    (toString in your example) that you want client code to use, not the
    helper method (abString).

    Another approach is to define the desired methods completely in the
    parent abstract class, not as abstract methods but with reasonable
    behaviors so the child class doesn't really have to override but may.
    That's the approach Object itself takes with these methods.

    Another approach is to declare toString and the others abstract in
    your base class.

    <sscce>
    package eegee;
    abstract class AbstractOver
    {
    @Override abstract public String toString();
    }
    public class ForceOver extends AbstractOver
    {
    @Override public String toString()
    {
    return getClass().getName();
    }
    }
    </sscce>

    --
    Lew
    Lew, Sep 8, 2009
    #8
  9. Mike Amling

    Daniel Pitts Guest

    Lew wrote:
    > Mike Amling wrote:
    >> I presume you recommend some kind of
    >> proxy to ensure toString, equals, hashCode, etc. are overridden:
    >>
    >> abstract class Basso {
    >> protected abstract String abString();
    >>
    >> public final String toString() {
    >> return abString();
    >> }
    >>
    >> }
    >>
    >> final class Extenso extends Basso {
    >> public String abString() {
    >> return "whatever";
    >> }
    >>
    >> }

    >
    > That's sort of a strange suite of methods to require overriding. It's
    > already best practice to override toString, hashCode and equals,
    > though not "etc.". (What other methods of Object do you contemplate
    > overriding? Not much else makes sense to override.)
    >
    > The pattern you show is a common one - define an abstract base class
    > with a public method that invokes abstract helper methods so that
    > subclasses can provide the varying parts. Often the abstract methods
    > are protected rather than public, since it's the wrapping method
    > (toString in your example) that you want client code to use, not the
    > helper method (abString).

    Yet another approach is to move those methods out of the class
    altogether, and use the Strategy pattern. This is my favored approach
    if there are a lot (read "more than one") of the "methods" that would
    need to be customizable, but mixing and matching the behaviors would
    make sense.

    This is kind of the upside down version of "Prefer Composition over
    Inheritance". You're still preferring Composition over Inheritance, but
    the main entity doing the preferring is what would have been the Base
    Class (rather than the Derived Class)


    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Sep 8, 2009
    #9
  10. On 08.09.2009 08:40, Lew wrote:
    > Roedy Green wrote:
    >> On Mon, 07 Sep 2009 23:20:32 -0500, Mike Amling <>
    >> wrote, quoted or indirectly quoted someone who said :
    >>
    >>> A certain class is used 80% of the time as is, and is extended 20%
    >>> of the time. I want to ensure that each subclass overrides a certain
    >>> method. The only way I can think of to do this is to put code in the
    >>> base class's constructors, and when the class being constructed is
    >>> not the base class, check that getDeclaredMethod does not throw a
    >>> NoSuchMethodException.
    >>> Does anyone know of a more efficient way? At compile time, maybe?

    >>
    >> The other way out of this is to put an assert in the method that must
    >> be overridden.
    >>
    >> It could use this.class to figure out if it is working with a base
    >> class or an extension. If they have overridden, the assertion won't be
    >> there.
    >> To get fancy you want to make it ok if they call super. You could look
    >> at the stack. See http://mindprod.com/jgloss/trace.html
    >>
    >> Others might have better ways of doing this with a run time check.

    >
    > Since the 'abstract' keyword works, and reflection is both messy and
    > slow, eschew reflection.


    Also, asserts are (and should be) OFF most of the time.

    > Any time you code an instance to figure out what class it is in order to
    > decide which behavior to use, you've messed up. (To nitpickers: that's
    > the first order of approximation.)
    >
    > (and the second)
    >
    > (...)
    >
    > You don't need a run-time check.


    Right.

    robert


    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Sep 8, 2009
    #10
  11. Mike Amling

    markspace Guest

    Daniel Pitts wrote:

    > Yet another approach is to move those methods out of the class
    > altogether, and use the Strategy pattern. This is my favored approach
    > if there are a lot (read "more than one") of the "methods" that would
    > need to be customizable, but mixing and matching the behaviors would
    > make sense.



    That's interesting. The classic solution to "mixing and matching
    behavior" is the Decorator Pattern. You have one decorator per
    behavior, and you mix and match by adding the decorators that are
    applicable. The advantage of decorators are that each class is a little
    more insulated from changes in other classes, I think. The disadvantage
    is that removing a behavior is more difficult (you have to unwind the
    stack of decorators, and make a new stack, skipping the decorator you
    want to remove).

    Your strategy pattern idea seems to make replacing/removing a behavior
    easier, but also (to me) seems to require a bit more complexity. Trade
    off, I suppose, depending on which operation seems more important to
    make easy and straightforward.



    > This is kind of the upside down version of "Prefer Composition over
    > Inheritance". You're still preferring Composition over Inheritance, but
    > the main entity doing the preferring is what would have been the Base
    > Class (rather than the Derived Class)



    Decorators use composition too, just wanted to point that out.
    markspace, Sep 8, 2009
    #11
  12. Mike Amling

    Daniel Pitts Guest

    markspace wrote:
    > Daniel Pitts wrote:
    >
    >> Yet another approach is to move those methods out of the class
    >> altogether, and use the Strategy pattern. This is my favored approach
    >> if there are a lot (read "more than one") of the "methods" that would
    >> need to be customizable, but mixing and matching the behaviors would
    >> make sense.

    >
    >
    > That's interesting. The classic solution to "mixing and matching
    > behavior" is the Decorator Pattern. You have one decorator per
    > behavior, and you mix and match by adding the decorators that are
    > applicable. The advantage of decorators are that each class is a little
    > more insulated from changes in other classes, I think. The disadvantage
    > is that removing a behavior is more difficult (you have to unwind the
    > stack of decorators, and make a new stack, skipping the decorator you
    > want to remove).

    I don't see how decorators are any more insulated than strategies.
    >
    > Your strategy pattern idea seems to make replacing/removing a behavior
    > easier, but also (to me) seems to require a bit more complexity. Trade
    > off, I suppose, depending on which operation seems more important to
    > make easy and straightforward.

    It requires minimal complexity, IMO, compared to decorators. Decorators
    do have there uses, but they the pattern I'm describing solves a
    different problem.

    I would only use Decorators in to extend behavior (performing the same
    behavior, but modifying the input and/or output of the extended behavior).

    If you are only modifying one behavior (method) of an object that has
    many behaviors, then it decorating it would lead to a lot of
    "pass-through" behavior.

    Using strategies instead allows you to group related methods in one
    interface, and only requires you to implement the strategies you care
    about changing. You can combine Decorators and Strategies as well, by
    having a Strategy be Decorated.

    >> This is kind of the upside down version of "Prefer Composition over
    >> Inheritance". You're still preferring Composition over Inheritance,
    >> but the main entity doing the preferring is what would have been the
    >> Base Class (rather than the Derived Class)

    >
    > Decorators use composition too, just wanted to point that out.

    Indeed they often do. However, in a different way than Strategy does.
    The various strategy objects are composed in the model. Where as the
    Decorators are composed of other Decorators or the Model object.

    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Sep 8, 2009
    #12
  13. Mike Amling

    markspace Guest

    Daniel Pitts wrote:
    >
    > I would only use Decorators in to extend behavior (performing the same
    > behavior, but modifying the input and/or output of the extended behavior).



    Yes, that's primarily the use-case I was thinking of. Of course there
    could be more complex interactions where decorators are not suitable.


    > I don't see how decorators are any more insulated than strategies.



    Primarily because they only do modify "input and output" and often only
    deal with one public method at a time, I think they're more encapsulated
    than certain other types of composition.
    markspace, Sep 9, 2009
    #13
  14. Mike Amling

    Roedy Green Guest

    On Tue, 08 Sep 2009 02:40:42 -0400, Lew <> wrote,
    quoted or indirectly quoted someone who said :

    >Since the 'abstract' keyword works, and reflection is both messy and slow,
    >eschew reflection.


    Granted, in this particular case, but for similar but more complex
    problems, run-time checking may be the way to go.

    It very rare you need to switch on the class of something in Java. It
    almost invariably means you missed an opportunity to solve the problem
    with OO.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "I mean, source code in files; how quaint, how seventies!"
    ~ Kent Beck (born: 1961 age: 48), evangelist for extreme programming.
    Roedy Green, Sep 9, 2009
    #14
  15. Mike Amling

    Roedy Green Guest

    On Tue, 08 Sep 2009 22:42:31 +0200, Robert Klemme
    <> wrote, quoted or indirectly quoted
    someone who said :

    >Also, asserts are (and should be) OFF most of the time.


    An assert on program structure needs to be on only once.

    I am not so sure about turning asserts off. Why?

    1. a clever compiler optimises them out or makes them low overhead.

    2. If things blow up at a client site, you want all the hints you can
    get.
    --
    Roedy Green Canadian Mind Products
    http://mindprod.com

    "I mean, source code in files; how quaint, how seventies!"
    ~ Kent Beck (born: 1961 age: 48), evangelist for extreme programming.
    Roedy Green, Sep 9, 2009
    #15
  16. Mike Amling

    Lew Guest

    Roedy Green wrote:
    > On Tue, 08 Sep 2009 22:42:31 +0200, Robert Klemme
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >> Also, asserts are (and should be) OFF most of the time.

    >
    > An assert on program structure needs to be on only once.
    >
    > I am not so sure about turning asserts off. Why?


    That is their purpose.

    The idea is that once you've proven the invariants, there's no need to keep
    proving them except when the code changes. The code doesn't change in
    production, by definition, it changes in development.

    > 1. a clever compiler optimises them out or makes them low overhead.


    Evidence?

    > 2. If things blow up at a client site, you want all the hints you can
    > get.


    That's what exceptions are for. And you can turn assertions on at the
    production site, at will, class by class, when you need those hints.

    The nature of invariants is that they're, well, invariant. Unlike exceptional
    conditions, they don't change from run to run. Once you lock them down, turn
    off the assertions. If you goofed, that's on your shoulders; then you have to
    turn them back on (perhaps partially) and correct your mistake before you turn
    them back off again.

    It's a common mistake to think assertions are exceptions. They aren't.

    Part of the reason for that mistake is that people don't analyze algorithms in
    terms of invariants enough. When you look at an assertion in the code, it
    often states the "obvious", as in:

    public void setLittleRabbit( Foo foo )
    {
    if ( foo == null )
    {
    throw new IllegalArgumentException( new NullPointerException(
    "foo == null" ));
    }
    this.littleRabbit = foo;
    assert this.littleRabbit != null;
    }

    This in turn allows the set invariant postcondition to be a get.. invariant
    precondition:

    public Foo getLittleRabbit()
    {
    assert this.littleRabbit != null;
    return this.littleRabbit;
    }

    Now, should someone subclass or alter this class and fracture the invariant,
    the asserts will raise the salute. Since they're turned on in development and
    all, you know.

    --
    Lew
    Lew, Sep 9, 2009
    #16
  17. On 09.09.2009 05:01, Roedy Green wrote:
    > On Tue, 08 Sep 2009 22:42:31 +0200, Robert Klemme
    > <> wrote, quoted or indirectly quoted
    > someone who said :
    >
    >> Also, asserts are (and should be) OFF most of the time.

    >
    > An assert on program structure needs to be on only once.
    >
    > I am not so sure about turning asserts off. Why?
    >
    > 1. a clever compiler optimises them out or makes them low overhead.


    They cannot be optimized away by the compiler because enabling and
    disabling them is a function of the JVM - not a compile time option.

    Regarding the overhead: depending on the algorithm needed to verify
    assertions they can take considerable runtime. This is nothing you want
    to invest all the time. I have more than once done something like

    assert classInvariant();

    private boolean classInvariant() {
    // complex calculation that returns true or false
    }

    As an example think of a class which contains a collection where only
    objects with certain properties are allowed. The invariant checking
    method might have to traverse the complete collection (which could be
    large) and test every single object. Whatever optimization you are
    going to make, you won't get this really fast.

    The nice thing about this is - and that's where the smartness lies -
    that the runtime won't even execute method classInvariant() at runtime
    if assertions are off for that class.

    As Lew excellently explained: assertions are to be used during
    development and test phases - not in production.

    Kind regards

    robert

    --
    remember.guy do |as, often| as.you_can - without end
    http://blog.rubybestpractices.com/
    Robert Klemme, Sep 9, 2009
    #17
  18. On 9 Sep., 11:45, Christian <> wrote:
    > Robert Klemme schrieb:> On 09.09.2009 05:01, Roedy Green wrote:
    > >> On Tue, 08 Sep 2009 22:42:31 +0200, Robert Klemme
    > >> <> wrote, quoted or indirectly quoted
    > >> someone who said :

    >
    > >>> Also, asserts are (and should be) OFF most of the time.

    >
    > >> An assert on program structure needs to be on only once.
    > >> I am not so sure about turning asserts off.  Why?

    >
    > >> 1. a clever compiler optimises them out or makes them low overhead.

    >
    > > They cannot be optimized away by the compiler because enabling and
    > > disabling them is a function of the JVM - not a compile time option.

    >
    > the JVM is the compiler ... its java  runtime is compiletime


    Roedy did not mention JIT. When I read "compiler" without further
    qualification in a Java forum this translates to "Java compiler".
    Strictly speaking JIT is purely optional while you always need a Java
    compiler to get bytecode from your sources.

    Anyway, that whole discussion is meaningless with regard to Roedy's
    statement that you want assertions on all the time. This is abusing
    assertions and not making best use of them.

    Cheers

    robert
    Robert Klemme, Sep 9, 2009
    #18
  19. In article <>,
    Mike Amling <> wrote:

    > A certain class is used 80% of the time as is, and is extended 20% of
    > the time. I want to ensure that each subclass overrides a certain
    > method. The only way I can think of to do this is to put code in the
    > base class's constructors, and when the class being constructed is
    > not the base class, check that getDeclaredMethod does not throw a
    > NoSuchMethodException.
    > Does anyone know of a more efficient way? At compile time, maybe?


    I'm not sure if this is useful, but it reminds me of "When an Abstract
    Class Implements an Interface" [1]:

    interface Interfaccia {
    String metodo();
    }

    abstract class Basso implements Interfaccia {
    // anything except metodo()
    }

    class Estesa extends Basso {
    // implementation of metodo() required
    public String metodo() {
    return "ciao";
    }
    }

    [1]<http://java.sun.com/docs/books/tutorial/java/IandI/abstract.html>

    --
    John B. Matthews
    trashgod at gmail dot com
    <http://sites.google.com/site/drjohnbmatthews>
    John B. Matthews, Sep 9, 2009
    #19
  20. Mike Amling

    Daniel Pitts Guest

    Robert Klemme wrote:
    > On 9 Sep., 11:45, Christian <> wrote:
    >> Robert Klemme schrieb:> On 09.09.2009 05:01, Roedy Green wrote:
    >>>> On Tue, 08 Sep 2009 22:42:31 +0200, Robert Klemme
    >>>> <> wrote, quoted or indirectly quoted
    >>>> someone who said :
    >>>>> Also, asserts are (and should be) OFF most of the time.
    >>>> An assert on program structure needs to be on only once.
    >>>> I am not so sure about turning asserts off. Why?
    >>>> 1. a clever compiler optimises them out or makes them low overhead.
    >>> They cannot be optimized away by the compiler because enabling and
    >>> disabling them is a function of the JVM - not a compile time option.

    >> the JVM is the compiler ... its java runtime is compiletime

    >
    > Roedy did not mention JIT. When I read "compiler" without further
    > qualification in a Java forum this translates to "Java compiler".
    > Strictly speaking JIT is purely optional while you always need a Java
    > compiler to get bytecode from your sources.
    >
    > Anyway, that whole discussion is meaningless with regard to Roedy's
    > statement that you want assertions on all the time. This is abusing
    > assertions and not making best use of them.

    Assertions are another way of catching bugs in production. If your
    assertions are causing a large performance penalty, then you can
    consider disabling them in production, or adjusting them to make more
    sense. Otherwise, leaving them in and on is considered a best practice.

    You don't need to test for all invariants everywhere, especially
    invariants that would cause an exception anyway (such as a collection
    must only contain objects of a certain class. That will be caught by a
    ClassCastException, which is a built-in assertion you can not disable)

    In other words, assertions should be used where failure of the invariant
    may change the output of the program in subtle ways, not where failure
    will itself cause an exception.



    --
    Daniel Pitts' Tech Blog: <http://virtualinfinity.net/wordpress/>
    Daniel Pitts, Sep 9, 2009
    #20
    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. Patel
    Replies:
    6
    Views:
    40,478
    Randall R Schulz
    Oct 23, 2003
  2. Patel
    Replies:
    1
    Views:
    402
    Harald Hein
    Oct 23, 2003
  3. jeremito
    Replies:
    22
    Views:
    552
    Bruno Desthuilliers
    Jan 6, 2007
  4. Hermann Lichte

    Overridden method doesn't get invoked

    Hermann Lichte, Oct 27, 2006, in forum: C++
    Replies:
    1
    Views:
    314
    Kai-Uwe Bux
    Oct 27, 2006
  5. Replies:
    0
    Views:
    358
Loading...

Share This Page