Does it make any sence?

[Georgy Bolyuba]

A little bit strange quiestion, but...

A friend of mine got this code during interview:

public interface A {
    void method();
}
 
public class ABase {
    public void method() {
System.out.println("method!");
    }
}
 
public class AChild extends ABase implements A {
}
 
public class ASample {
    public static void main(String[] args) {
A a= new AChild();
a.method();
    }
}

As you can see there is something like "indirect realization" in this code. My friend was asked: "Where it might be usefull?"

He asked me. Now I'm asking you.

[Stan James]

This makes me uncomfortable. ABase has the method we need, but it doesn't claim to know anything about the interface. It might have the signature but do something completely undesirable with it. AChild glues together the interface which promises certain behavior and superclass which does not.

Of course polymorphism is all about doing different things with the same signature and I like to be able to introduce new unpredicted behavior at runtime, so maybe AChild takes responsibility for knowing the ABase really does the right thing. This still looks like a trick to sneak ABase into someplace it doesn't belong.

Back in VB4 days we used to practice what I called "polymorphism by coincidence". A method gets a parameter of unknown type and tries to call a method on it. If the parameter object has that method you go merrily on your way. If not then "on error goto" does something else. Does that sound similar?

[Ilja Preuss]

It looks like kind of a trivial class based Adapter: AChild adapts ABase to the A interface. This is useful if the developer of ABase didn't know anything about the A interface (for example if ABase is part of a thirdparty library).

[Mr. C Lamont Gilbert]

I agree Ilja almost. Problem is child class does not adapt base class. it just wears an interface and inadvertently opens itself up to new usages.

I think this is bad code, but you can't really say that in the interview can you? I use tyis type of thing myself, but the base classes methods would never be public, but default access. I would then publish them by forwarding calls to super.

As it stands the interface almost seems to be scavaging for any class that fits its signature

Maybe im too uptight.

[Devesh H Rao]

public interface A {
    void method();
}
 
..............
}

.............. Now I'm asking you.[/qb]

---

</blockquote>


Makes sense to me if ASample is a customized class for specific clients, ABase is the core of a product and AChild and A are used as switch to turn on or off specific features of the product for a client.

The product ABase core can contain all the business functionality which is common across clients, AChild can build on client specific functionality and A can be used to provide conditional access.
[ November 03, 2005: Message edited by: Devesh H Rao ]

[Georgy Bolyuba]

Originally posted by Mr. C Lamont Gilbert:
I agree Ilja almost. Problem is child class does not adapt base class. it just wears an interface and inadvertently opens itself up to new usages.

This code is definitely looks like adapter for me. But I've asked my question because I cannot spot the problem and I was sure that there is some thing strange in that code. Now I can say the problem is in inadvertence . That is why I was confused.

As it stands the interface almost seems to be scavaging for any class that fits its signature

Sorry, but I didn't get this phrase.

[Georgy Bolyuba]

Originally posted by Devesh H Rao:

Makes sense to me if ASample is a customized class for specific clients, ABase is the core of a product and AChild and A are used as switch to turn on or off specific features of the product for a client.

The product ABase core can contain all the business functionality which is common across clients, AChild can build on client specific functionality and A can be used to provide conditional access.

It's understandable, but I think this is not the best way for customize your code.

[Georgy Bolyuba]

Originally posted by Stan James:
This makes me uncomfortable. ABase has the method we need, but it doesn't claim to know anything about the interface. It might have the signature but do something completely undesirable with it. AChild glues together the interface which promises certain behavior and superclass which does not.

Of course polymorphism is all about doing different things with the same signature and I like to be able to introduce new unpredicted behavior at runtime, so maybe AChild takes responsibility for knowing the ABase really does the right thing. This still looks like a trick to sneak ABase into someplace it doesn't belong.

Back in VB4 days we used to practice what I called "polymorphism by coincidence". A method gets a parameter of unknown type and tries to call a method on it. If the parameter object has that method you go merrily on your way. If not then "on error goto" does something else. Does that sound similar?

Eah... It might be one of the good reason for writing this code.

As for me I think it would be good idea to add this method to AChild

public void method() {
    super.method();
}

Or maybe it is good idea for compiler to spot inadvertences like that?

[Ilja Preuss]

Originally posted by George Bolyuba:

public void method() {
    super.method();
}

What would be the advantage of doing this?

[Mr. C Lamont Gilbert]

I see.

If ABase is an A then it should implement the interface itself. If ABase is a base class for other classes that will implement A then ABase should implement A and be declared abstract.

in this case I suppose we are saying ABase is not an A, but is being adapted to an A by AChild. So the class names are misleading. AChild is not a 'child' but is an adapter.

This is definitely a better choice than putting the A on ABase itself and is probably one proper way to perform multiple inheritance.

[Georgy Bolyuba]

Originally posted by Ilja Preuss:

public void method() {
    super.method();
}

What would be the advantage of doing this?

---

</blockquote>

I think this can make code easer to understand. It's like if AChild said: "Im sure that method() of ABase is implemeting mathod() of A. Trust me." And in code from my first post it look like AChild knows nothing about method().

[Ilja Preuss]

Originally posted by George Bolyuba:

I think this can make code easer to understand. It's like if AChild said: "Im sure that method() of ABase is implemeting mathod() of A. Trust me." And in code from my first post it look like AChild knows nothing about method().

On the other hand it also reduces encapsulation - if method() changes (for example it gets an additional parameter), more code needs to be adapted, which is a bad thing.

I find that I once you get a hang of OO, you begin to trust code and become able of concentrating on well encapsulated behaviour without having to also know every little detail about the context. And for the cases where you really want to know, a good IDE can help (for example, pressing ctrl-shift-o twice in Eclipse will show you all implemented *and* inherited members of the current class).

[Georgy Bolyuba]

Thanks everybody for your answers. I think now this subject is clear for me.