views:

649

answers:

2

Referring here

A is a precompiled Java class (I also have the source file) B is a Java class that I am authoring
B extends A.

How can logic be implemented such that A can call the methods that B has.
The following are the conditions:

  • I don't want to touch A(only as a last option though that is if no other solution exists).
  • I don't want to use reflection.

As stated, if needed I could modify A. What could be the possible solution either way?

+7  A: 

Class A should define the methods it's going to call (probably as abstract ones, and A should be an abstract class, per Paul Haahr's excellent guide); B can (in fact to be concrete MUST, if the method are abstract) override those methods. Now, calls to those methods from other methods in A, when happening in an instance of class B, go to B's overrides.

The overall design pattern is known as Template Method; the methods to be overridden are often called "hook methods", and the method performing the calls, the "organizing method".

Alex Martelli
Great, concise answer.
San Jacinto
@ AlexClass A is some sort of library class and its not abstract.To use the library I am extending A.What do I do in this case?
Kevin Boyd
@unknown, glad you liked it!-)
Alex Martelli
@Kevin, if it's a library class then it cannot sensibly know about application-level classes -- that's WAY the wrong direction for a dependency arrow! Look up Dependency Inversion: make an interface (it's perfectly fine to depend on abstract things such as interface) and have your application class implement that, use Dependency Injection to supply the library class instance with the interface implementation it needs to make calls on. BTW, if the library supplies concrete classes and yet requires you to extend them, its design is dubious: send Haahr's essay to the lib's architect(s)!-)
Alex Martelli
@Alex: I understood the first part that is B implements Interface I, what is Dependency Injection?Doesn't A need to hold a reference of I to call B's methods then? should I insert a field private Inteface I in Class A?
Kevin Boyd
Dependency Injection (search for it!) can be implemented in many ways (there are frameworks that automate it, and many manual approaches) but it does boil down to A holding a private reference to an interface I (otherwise, where would it call I'd methods?-). As you're keen on having B (which extends A) implement I (breaking the Design Pattern First Two Principles: program to an interface, not to an implementation; prefer composition to inheritance), either have A take I in its constructor that B call, or a `setTheI` setter (which B's constructor can call with `this` as the argument).
Alex Martelli
@Alex, except that if B extends A and B is also the implementation of I, then A can't take the I in it's constructor because that would result in super(this), which will be bounced as a reference to this before the invocation of super() is complete; you would need to get ugly with something like a private instance method which returned I, like: private I returnMe() { return this; }
Software Monkey
@Software Monkey, then the `setTheI` setter approach is clearly simpler and sounder (in other languages there's no problem passing a pointer or reference to this/self to super's constructor, so either approach would be fine).
Alex Martelli
A: 

I would be rather hesitant to do this. Please correct me if I am wrong and then I will delete, but it sounds like you want to maintain an A object along with a B object. If they indeed are not the same object, the "tying together" (that's a scientific term) you'll have to do would be pretty ugly.

San Jacinto
I'm sorry I did not understand the question, could you rephrase it please?
Kevin Boyd
@kevin-Boyd please examine Alex-Martelli's 2nd comment to his answer (the long one). He is pointing out the same thing i was trying to say.
San Jacinto