I want to access all the methods(non-abstract+abstract) from Class A
.
So i extended Class A
, but here in Class B
i want to access all non-abstract methods and only 10 abstract method - as I dont want to implement rest of the abstract methods of class B
.
Problem:
1.I can't extend Class B
because i have already extended Class A
.
2.I can't put those 10 methods inside an interface because i also want to access the non-abstract methods from class B
.
what should be the correct approach to reuse those methods?.
class A
abstract class A{
public void m1(){
//do stuff
}
public void m2(){
//do stuff
}
// +30 more non abstract methods
public abstract void n1();
public abstract void n2();
// +30 more abstract method
}
class B
abstract class B{
public void a1(){
//do stuff
}
public void a2(){
//do stuff
}
// +30 more non abstract methods
public abstract void b1();
public abstract void b2();
// +30 more abstract method
}
class C
class C extends A{
public void n1(){
//do stuff
}
public void n2(){
//do stuff
}
//+30 more abstract methods implemented
//But here i want all the non abstract methods and only 10 abstract methods of B
}
The serious non-answer here: stop; and step back now. Forget about doing this.
Chances are extremely high that your design is already in a very bad shape. As you should always prefer a complex network of simple classes over a simple network of complex classes.
Inheritance is much more than just writing down A extends B
. It starts with: in that case, any A is-a B. Alone the number of methods you mention in your question indicate that your classes do not follow that simple rule; and probably they are violating others, too.
Thus: do not waste your time to understand how to add another 10 to to the other 30 methods in your class. Spend your time to throw away everything; and build a real OO model.
You would start by understanding the problem domain; to derive meaningful, helpful classes from that. Classes that focus on the problem to solve. Classes that follow the SOLID rules. Or remember the good old FCoI paradigm.
Long story short: I would consider a class with more than 10 methods to be subject for refactoring; but 30 abstract methods; that sounds (sorry) (almost) outright crazy.
Edit, on some of the comments: of course, it is possible that the OP has in fact a reasonable design; as there are examples of classes that come with a lot of methods (think of a typical Swing UI component for example). But (imho) the likelihood of a "bad" design is simple pretty high when dealing with a large number of abstract methods.