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
}
A method which does not have body is known as abstract method. It contains only method signature with a semi colon and, an abstract keyword before it. public abstract myMethod(); To use an abstract method, you need to inherit it by extending its class and provide implementation to it.
A class which is declared as abstract is known as an abstract class. It can have abstract and non-abstract methods.
An abstract class is a class that is declared abstract —it may or may not include abstract methods. Abstract classes cannot be instantiated, but they can be subclassed. When an abstract class is subclassed, the subclass usually provides implementations for all of the abstract methods in its parent class.
A: Java has a rule that a class can extend only one abstract class, but can implement multiple interfaces (fully abstract classes).
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With