enforce override of method

Thread view:

Mize-ze - 25 Jun 2007 22:29 GMT

Hi,
Let's say I have a class A which implements interface I, which has a
method foo() in it,
I want (and I must) implement I.foo() method in class A.

Now, I have a Class B which extends A and therefore inherits it's
foo() method. however,
I don't want class B to use A's implementation of foo() but instead
implement its own .
I can easily just override the method by implementing the foo() method
in B.

BUT what if I want to enforce the user to implement foo()?
Anyway of doing this?
It's like having class A as abstract class( foo() as abstract). but it
isn't...

Thanks.

Reply to this Message

Matt Humphrey - 26 Jun 2007 00:39 GMT

| Hi,
| Let's say I have a class A which implements interface I, which has a
[quoted text clipped - 12 lines]
| It's like having class A as abstract class( foo() as abstract). but it
| isn't...

If B must extend A and foo must be accessible outside of the package, there
is no way to enforce that B.foo() not override or use A.foo(). If there
were a way to enforce it, B could always write a method fooAlt () which
calls foo() (because foo is accessible) and then let B.foo () "override" by
calling fooAlt().

If foo can be restricted to the package, A can give it default protection.
n that case B would then not have any access to it, but no code outside of
the package could use A.foo either. B.foo would be available, but it would
be different from A.foo and would not override it.

Matt Humphrey matth@ivizNOSPAM.com http://www.iviz.com/

Reply to this Message

Mize-ze - 26 Jun 2007 01:12 GMT

> | Hi,
> | Let's say I have a class A which implements interface I, which has a
[quoted text clipped - 25 lines]
>
> Matt Humphrey m...@ivizNOSPAM.comhttp://www.iviz.com/

Hi Matt,
I'm afraid I wasn't that clear,
I want to have a situation where if one of my developers wants to
extend A he HAS to override
foo() and not use A's implementation (although he can trick the system
by calling it at fooAlt, that's fine by me...)

Bottom line:
I want he's class not to compile until he implements foo().

Reply to this Message

Zig - 26 Jun 2007 01:56 GMT

Inheritence can't give you what you are looking for, but if you consider
delegation, you might get the desired effect.

eg:

public class A implements I {
    private final I _delegate;
    protected A(I imp) {
        if (imp==null) throw new NullPointerException();
        _delegate=imp;
    }
    public void foo() {
        _delegate.foo();
    }
    public static A createDefaultA() {
        return new A(new I() {
            public void foo() {
                // default foo method
            });
    }
}

>> | Hi,
>> | Let's say I have a class A which implements interface I, which has a
[quoted text clipped - 40 lines]
> Bottom line:
> I want he's class not to compile until he implements foo().

Reply to this Message

Zig - 26 Jun 2007 02:14 GMT

Just forgot the more obvious, if you are willing to make A abstract, you
can also make it a factory with an anonymous implementation

public abstract class A implements I {
    protected A() {
    }
    public static A createDefaultA() {
        return new A() {
            public void foo() {
                //default foo
            }};
    }
}

Now, subclass B must implement foo, but users can still get a reasonable
default implementation (not elsewhere exposed or inheritable).

> Inheritence can't give you what you are looking for, but if you consider
> delegation, you might get the desired effect.
[quoted text clipped - 65 lines]
>> Bottom line:
>> I want he's class not to compile until he implements foo().

Reply to this Message

Twisted - 26 Jun 2007 01:20 GMT

> If B must extend A and foo must be accessible outside of the package, there
> is no way to enforce that B.foo() not override or use A.foo(). If there
[quoted text clipped - 6 lines]
> the package could use A.foo either. B.foo would be available, but it would
> be different from A.foo and would not override it.

Rethink the class hierarchy. What you want isn't I->A->B; you want

-> A
I -> ABase
-> B

with ABase having an abstract foo() method and otherwise all the code
of your original A class, and A just being a final subclass with an
implementation of foo. Anyone who wants to make B has to subclass
ABase instead of A (which is final), and then override foo (which is
abstract), and can't use super.foo (since it's abstract) or A.foo
(which is not applicable to "this").

Reply to this Message

Ingo R. Homann - 26 Jun 2007 09:04 GMT

Hi Mize-ze,

> Rethink the class hierarchy. What you want isn't I->A->B; you want
>
[quoted text clipped - 8 lines]
> abstract), and can't use super.foo (since it's abstract) or A.foo
> (which is not applicable to "this").

I'm not sure if you are aware that the following solution is also
possible (although I suspect that Twisted's or Zig's solution might be
the better one for your problem):

interface I {
void foo();
}

class A implements I {
public void foo() {}
}

abstract class B_Base extends A {
public abstract void foo();
}

class B extends B_Base {
// compiler error: foo() not implemented!
}

Ciao,
Ingo

Reply to this Message

Twisted - 26 Jun 2007 09:27 GMT

> I'm not sure if you are aware that the following solution is also
> possible (although I suspect that Twisted's or Zig's solution might be
> the better one for your problem)

I've now seen Zig's posting, and he eventually arrived where I did by
a circuitous route, aside from his A being an anonymous implementation
returned by an ABase factory method instead of a standalone public
final class. (My names for the classes but describing his structure.)

> class A implements I {
> public void foo() {}
[quoted text clipped - 10 lines]
>
> }

Nothing here is stopping someone directly extending A. And A can't be
made final or B_Base can't exist.

A could be given only package-private constructors and B_Base (in the
same package) a protected or public one. Then it more-or-less works,
unless someone's willing to define their class into someone else's pre-
existing package. :)

However, my version gives what I feel to be a cleaner type hierarchy
-- logically, there is A-that-can-be-extended-but-requires-foo-
implementing and A-that-is-a-directly-usable-implementation.
Separating those into abstract ABase and final A tidies up and keeps
what should be subclassed determined by "final" rather than
constructor hijinks.

And of course anyone who mentions that A's constructor could have code
like "if (!(getClass().equals(A.class)) && !(this instanceof B_Base))
throw..." will be flamed to a crispy br<claps hands over mouth and
turns red>

Reply to this Message

Ingo R. Homann - 26 Jun 2007 10:07 GMT

Hi Twisted!

>>class A implements I {
>> public void foo() {}
[quoted text clipped - 13 lines]
> Nothing here is stopping someone directly extending A. And A can't be
> made final or B_Base can't exist.

Well, of course, Mize-ze has to provide B_Base, so it *will* exist. The
other point (directly extend A) is true but can be solved as you showed
(package-private constructor). Anyhow...

> However, my version gives what I feel to be a cleaner type hierarchy
> -- logically, there is A-that-can-be-extended-but-requires-foo-
> implementing and A-that-is-a-directly-usable-implementation.
> Separating those into abstract ABase and final A tidies up and keeps
> what should be subclassed determined by "final" rather than
> constructor hijinks.

...I totally agree to this. (That was what I meant with "Twisted's ...
solution might be the better one".)

> And of course anyone who mentions that A's constructor could have code
> like "if (!(getClass().equals(A.class)) && !(this instanceof B_Base))
> throw..."...

:-)

Ciao,
Ingo

Reply to this Message

stefanomnn - 26 Jun 2007 10:46 GMT

> Hi,
> Let's say I have a class A which implements interface I, which has a
[quoted text clipped - 14 lines]
>
> Thanks.

in implementation of foo in class A,
try so:

if(this.getClass().equals(A.class)==false) {
// "this" is an instance of a sub-class
throw new NoSuchMethodException();
}

Reply to this Message

Mize-ze - 26 Jun 2007 22:13 GMT

I've took your advice and did some re-thinking.
I made an abstract ABase with abstract foo()

So now my A and any other "ABases" (such as B) will directly extend
ABase.

Thanks

> > Hi,
> > Let's say I have a class A which implements interface I, which has a
[quoted text clipped - 27 lines]
>
> - Show quoted text -

Reply to this Message

Philipp Leitner - 26 Jun 2007 22:26 GMT

> in implementation of foo in class A,
> try so:
[quoted text clipped - 4 lines]
>
> }

This looks like awful design, and it won't do what the OP wanted. This
solution will just throw an Runtime Exception, while the OP wanted a
statically safe solution.

Reply to this Message

enforce override of method

Free Magazines