Tricky inheritance question
I'm wondering if it's possible to reduce the functionality of a parent class selectively. Specifically, the JComponent class contains a method called processKeyBinding, which is extended by JTable. What I want to do is create a new class, based on JTable, which removes the functionality added to that method but preserves the functionality of any higher class in the hierarchy. Note that I am NOT trying to do this:
publicclass MyTableextends JTable
{
// ...
protectedboolean processKeyBinding(...)
{
super.processKeyBinding(...);
}
}
And I am also NOT trying to do this:
publicclass MyTableextends JTable
{
// ...
protectedboolean processKeyBinding(...)
{
}
}
Ideally, what I'd like to do is something along the lines of the following:
publicclass MyTableextends JTable
{
// ...
protectedboolean processKeyBinding(...)
{
JComponent.processKeyBinding(...);
// or
super.super.processKeyBinding(...);
}
}
Obviously, that won't compile, but you see what I'm aiming for here. I want to prevent JTable's version of the processKeyBinding method from ever being triggered, while maintaining any higher class's implementation of it. Is this possible or am I wasting my time?
(background info: the reason I want this is to prevent a keystroke in my table from launching the current cell's editor component. If there's a better way to do that please let me know, otherwise I'll assume the above approach is the only way.)
[2626 byte] By [
scorbett] at [2007-9-26 2:50:01]
There's no language support for something like [b]super.super[/b], but you can work around it by declaring an extra method.
[code]class A {
public void method() {
System.out.println("A's implementation of method");
}
}
class B extends A {
protected void originalMethod() {
super.method();
}
public void method() {
// this overrides A.method();
}
}
class C extends B {
public void method() {
// restores A's implementation of method()
originalMethod();
}
}
> There's no language support for something like
> [b]super.super[/b], but you can work around it by
> declaring an extra method.
>
> [code]class A {
> public void method() {
> System.out.println("A's implementation of
> on of method");
> }
> }
> class B extends A {
> protected void originalMethod() {
> super.method();
> }
> public void method() {
> // this overrides A.method();
> }
> }
> class C extends B {
> public void method() {
> // restores A's implementation of method()
> originalMethod();
> }
> }
This does not help him. He has no control over class A (JComponent) or class B (JTable). He only has control over class C (his table).
Actually,
I agree most with the last remarks about bad design, but in a different way. The only reason you can't do what you want to do is because most existing OO languages are hideously POOR at OO. OO concepts embrace the notion that you should be able to iterate over a non-homogenous collection and trigger functionality without knowing the type of the objects involved. You can't even come close to that behavior in C++ or Java, but I understand Smalltalk may support it. If you think you are doing this now, I would refer you to the Object class - which is the lowest class that YOU MUST KNOW ABOUT to handle a collection at all - But Object doesn't do squat for you! - SO, Prepare to CAST!)
Anyway, referring back to the original question, I think you are saying this...
public class MyTable extends JComponent
{
JTable jTable = new JTable();
// Map all desired JComponent calls to the JTable data member
// and from here on out, you are completely in the driver's seat!!
.
.
.
}
