I'm working with a certain API library in Java. It has a base class A, as well as B and C which both extend A. B & C provide similar but distinct functionality, all three classes are in the library.
public abstract class A
{
virtual foo();
}
public class B extends A {}
public class C extends A {}
How do I get elements of A, B, and C in my class? If I use interfaces to implement the classes, there is a lot of duplicate code, and inner classes will not allow me to override existing methods so that the calling interfaces of A, B, and C are preserved.
How do I implement multiple inheritence in Java?
EDIT:
Thanks for edit George, its more clear now, forgot to mention one critical requirement: my classes must have A as a base so that they can be managed by platform API.
To recap, you have:
class A
{
public void foo() {}
}
class B extends A
{
public specificAMethod() {}
}
class C extends A
{
public specificCMethod() {}
}
The above classes are in a library that you can't access or modify.
You want to get the behaviour of both B and C in a third class D, as if it were possible to write:
class D extends B, C
{
}
Right?
What about using B and C instead of inheriting? Do you really need inheritance? You want to call private B and C methods?
class D
{
private B b;
private C c;
}
If you take the general approach of "Prefer Composition over Inheritance", you may find out that one or both of the classes shouldn't be actually "Inherited" anyway. In both cases, do the classes have a strict "is-a" relationship? If you can say "Has-a" out loud and it doesn't sound stupid, you probably want composition.
For instance, if you are implementing a deck of cards, the 3 of spades is-a 3 and it is-a spade, but you can also think of it as it has-a 3 and it has-a suit (spade). Since you can think of it that way, you should probably prefer the has-a interpretation and use composition.
Try to stay away from inheritance trees more than a few objects deep--and if you ever feel the desire to use multiple inheritance, try to work around it. This is one of the cases where Java kind of forces you to design your code to be a little more readable by not supplying a feature (but admittedly when you really want it, it's not there and that can hurt! Some level of mixin would be nice).
Sounds like you want to extend A - call it D - override its foo(), and then have new subclasses E & F that extend D and add their own functionality.
You might think about extracting common interfaces and reusing those. A good IDE with refactoring capability will make it easy to do.
Multiple class inheritance is not possible in Java, however you can use multiple inheritance for interfaces. Using Delegation pattern you can combine behavior of several other classes into one.
Completely different approach is applied in COM: all objects inherit from IUnknown, which has a method that could be translated to Java as:
Object queryInterface(Class<?> clazz)
The simplest implementation of this method can be:
if(clazz.isAssignableFrom(this.getClass()))
return this;
else
return null;
Where single inheritance won't work, it's just enough to add:
else if(class == SomeClass.class) {
return something;
} else ...
This way even most complex multiple inheritance cases can be tackled and you get full control over what is returned and when, so you avoid many problems with 'classical' multiple inheritance from languages like C++, like fork-join problem.
Since Java 1.8 you can use interfaces with default methods. It's very handy and I tend to use it a lot. Covariant return types are supported, too. There are a fiew restricktions (see below), but you dont have to implement the inheritence by your self and let the compiler work for you.
public interface A {
default A foo() {
return this;
}
}
public interface B extends A {
#Override
default B foo() {
return this;
}
}
public interface C extends A {
#Override
default C foo() {
return this;
}
}
public interface D extends B, C {
#Override
// if the return type does not implement B and C
// the comiler will throw an error here
default D foo() {
return this;
}
}
Note that this but note that you cant call super.foo or define fields or private members (until Java 9) since its still interfaces. If you get along with this restrictions, this opens up you a new level of object oriented programming.
Related
Suppose I have the following code...
interface A{
void a();
}
interface B extends A{
void b();
}
class ImplementOne implements B{
public void a(){};
public void b(){};
}
class ImplementTwo implements B, A{
public void a(){};
public void b(){};
}
Regardless of whether class ImplementTwo implements both B and A, or just B, it would still need to implement method a() in interface A, since interface B extends interface A. Is there any reason one would explicitly do
...implements B, A
instead of just
...implements B
?
There is no difference between the two approaches in terms of behavior. In terms of bytecode information, there is a small difference when it comes to information about implemented interfaces. For example:
Class<?>[] interfaces = ImplementTwo.class.getInterfaces();
for (int i = 0; i < interfaces.length; i++) {
System.out.println(interfaces[i]);
}
would return two class instances when implements B, A is used, whereas when using implements B it would return one instance.
Still, the following returns true using both approaches:
A.class.isAssignableFrom(ImplementTwo.class)
IMO the only reason you would want to specify it explicitly like that is if you were attempting to make the code more easily readable by others who needed to interact with it. That even being said, really, a two-step indirection like this is not so abstract that it's difficult to follow, so I don't really think this would ever have a need to happen.
The most famous example is of the use of the interface Serializable.
This is often repeated for the purpose of: Should the super interface suddenly gets detached from Serializable interface, it's sub-interface will still remain Serializable since it's already defined as Serializable.
This often occurs doing code refactoring. Other than that, there is no difference.
Both variants are exactly the same semantically. You might prefer one over the other for stylistic reasons (for example, to make it immediately clear to the reader of the class that it implements both A and B).
There is no difference in how the code will behave (or compile).
Some people prefer explicitly listing all implemented interfaces even if they are enforced by another interface implemented. It's purely a matter of personal/code style preferences.
Both approaches are equal. You might choose implements A, B instead of implements B to specify whole list of types for object ithout knowledge about A-B hierarchy
In this case it doesn't make difference. But technically you could have two interfaces which are not related one to other with same method declaration. And this implementation would implement method for both interfaces.
I very well know that it can be done with the help of interfaces and i have done it many times. But this time my situation is quite difference. I have class A , class B and i need to create another class C which extends both A and B because C should have boths functionality and also note that A and B are not inter related so even i cant say A may extend class B.
I am quite confused what should i do right now. I know we cant change java... but at least there would be some way possible. Even the nearest may also do... please help me out.
Adding more details:- Class B is a standard API while class A is a common exception class that need to be inherited by all exception classes.
Related question:
Why is there no multiple inheritance in Java, but implementing multiple interfaces is allowed? (though my question above is not about why it's not allowed.)
This is typically solved using object composition.
This is also advocated in Effective Java, Item 16: Favor composition over inheritance.
Java restricts a class from having an is a-relation to two (unrelated) classes. It does not however restrict a class from having the functionality of two unrelated classes.
class A {
void doAStuff() {
System.out.println("A-method");
}
}
class B {
void doBStuff() {
System.out.println("B-method");
}
}
// Wraps an A and a B object.
class C {
A aObj;
B bObj;
void doAStuff() {
aObj.doAStuff();
}
void doBStuff() {
bObj.doBStuff();
}
}
(Alternatively you could have class C extends A and only create wrapper methods for B, but keep in mind that it should make sense to say C is an A.)
I have a design pattern that need to be followed and for that its compulsory to extend
This is, as you probably know completely impossible. You could however create proxy classes for A and B that delegate the functionality to the C-instance. For instance by adding these two methods to the C-class above:
class C {
// ...
public A asAObject() {
return new A() {
#Override
void doAStuff() {
C.this.doAStuff();
}
};
}
public B asBObject() {
return new B() {
#Override
void doBStuff() {
C.this.doBStuff();
}
};
}
}
http://en.wikipedia.org/wiki/Adapter_pattern
Your problem is solved by the adapter pattern. I went back to check the wiki document, just to be sure :)
It is not possible to extend two classes, and thus inherit functionality from both, in Java. Your easiest alternative it to "wrap" at least one of the two classes. So, instead of also extending B you can have an instance of B inside C, and declare each of B's methods on C, and pass them through. C would not "be" a B, but it sounds like you just want to inherit functionality. And if that's true of A too, then, well, you should be using this pattern for both A and B and not extending either.
Make use of composition. Class C will contain an instance each of classes A and B.
You may try create class C that will contain one instance of class A and one of class B and their methods (create methods with same names that will just call methods from A and B), it's called Composition - another method in opposite to inheritance. Of course that's in case if you don't need instanceof to work with that C class.
A common oop principle is "choose composition over inheritance", since you can't extend 2 classes I would suggest having one of or both of those classes as members of Class C, that is of course if that works for what you are trying to do.
Maybe you can create a new class D, and have both class A and class B inherit from D?
Change the way you are thinking. Think in interfaces. It means that class A is actually an implementation of interface A' and class B is an implementation of interface B'. And you actually want a class C that implements both interfaces A' and B'. Class C doesn't need to extend anything or to use any particular pattern or whatsoever. It can extend A and delegate some methods to B, or it can extend B and delegate some methods to A. Or it can delegate all methods to A and B - implementation is your decision.
I'm porting some Python code to Java, and I am having trouble dealing with the following problem:
I have some classes which need to have abilities A, B, or C. Class 1 needs ability A, class 2 needs A, B and C, and class 3 needs B and C. Most importantly, I want to easily be able to change what class can have what ability in the future.
I solved this problem pretty easily with multiple inheritance in Python. I'm trying to figure out the best way to do it in Java, but I can't come up with as good of a solution. I know multiple inheritance is frowned-upon, so I'd appreciate being taught a better way.
Thanks!
It depends on your actual use case, but have you already considered decorators?
http://en.wikipedia.org/wiki/Decorator_pattern
Multiple-inheritance ain't frowned upon. What is frowned upon is "implementation inheritance" (also known as "code reuse"), because it leads to the unsolvable "diamond problem". And because, well, code-reuse really hasn't much to do with OO.
What you want to do can be solved using multiple inheritance (and, say, delegation if you need to do "code reuse").
interface A {
void move();
}
interface B {
void eat();
}
interface C {
void think();
}
class One implements A { ... }
class Two implements B { ... }
class Three implements B, C { ... }
Any OOA/OOD using multiple inheritance can be trivially translated to Java. The part where you say that you need to change the "ability" all the time is a bit scary: if, say, a Car can move(), why would it suddenly need to be able to think()?
You can use AspectJ's mixin syntax fairly easily to emulate multiple inheritance (and at compile time too). First, declare an interface for the functionality you want to mixin:
public interface A{
String getSomethingForA();
}
then define an annotation which you can use to signify that you want the mixin applied to a given class:
public #interface WithA {}
then add the annotation to the class you want to use:
#WithA
public class MyClass {}
then, to actually add some functionality:
#Aspect
public class MixinA {
public static class AImpl implements A{
public String getSomethingForA() {
return "it worked!";
}
}
#DeclareMixin("#WithA *")
public static A get() {
return new AImpl();
}
}
You'll need to use the aspectj jars and run the aspects as part of your compile process, but this lets you create truly modularized functionality and then forcibly merge it into your classes later. To access your class with the new functionality, do the following:
MyClass obj = new MyClass();
((A)obj).getSomethingForA();
You can apply the same annotation to another class and cast it as well:
#WithA
#WithB //let's pretend we created this with some other functionality
public class AnotherClass {}
AnotherClass anotherObj = new AnotherClass();
((A)anotherObj).getSomethingForA();
((B)anotherObj).andSetSomethingElseForB("something else");
Multiple inheritance is almost always a bad idea, as its effects can usually be achieved through other mechanisms. Based upon your description of the problem, it sounds like you want to
Use interfaces to define behavior (public interface A) in this scenario, each behavior should probably have its own interface.
If 2 behaviors are tightly coupled (say A & B), define an interface that implements those two atomic interfaces (public interface CombinedAandB extends A, B)
Define an abstract base class that implements the interface to provide default implementations for behaviors
public abstract class BaseAB implements A, B
{
#Override
public void A() { add(0,1); }
#Override
public void B() {add(1,0); }
private void add(int a, int b) //it doesn't return. no soup for you.
{ a + b; //If you know why this is wrong, high five yourself. }
}
Define a concrete class that extends the abstract base class, implements another interface, and provides its own behavior.
public class IDoABAndC extends BaseAB implements C
{
//stuff, etc
}
You can define the abilities in interfaces and implement them in your classes.
In java you don't have multiple inheritance, instead you can implement multiple interfaces.
So your class 1 will implement interface A and B. Class 2 will implement interface A, B and C. Class 3 will implement B and C.
If what you need is interface inheritance, then as mentioned before, you can always implement multiple interfaces.
If you're looking for implementation inheritance, you're somewhat out of luck. The best solution is probably to use delegation — replace the extra superclasses with fields, and implement methods that just delegate to those fields. It does require writing a lot of repetitive delegation methods, but it's rather unavoidable in Java (without resorting to AspectJ or other bytecode-munging tricks; careful, this way madness lies …).
This is a bit tangential, but you can have python code running in Java via Jython (http://www.jython.org/). This addresses the porting to Java part, not the solving multiple inheritance part (I think you need to determine which is relevant)
hi i am new to java....moved from objective c (iphone background)
all we know that
here we cannot use multiple inheritance....
alternative way is interface......
my question is...... does inheritance through interfaces make any sense...because we have to define the code of function in our class.......only helping part here is variables...
it is like a single .h class in objective c...
i am talking about only functions of that interface...why to declare there....just to save 2 or three lines...that's it..
please tell why there is no multiple inheritance(simple reason...).
i know this may be a bad question to ask but.........
i am in little bit of dark please help.....
I love this answer of Stephan Schmidt . he's clearly explained about this,
http://codemonkeyism.com/java-interview-questions-mutliple-inheritance/
Does Java support multiple inheritance?
Well, obviously Java does not have multiple inheritance in the classical sense of the word. So the right answer should be “no”, or “no, but” or “yes, but”. From there one can explore several ways. Mostly I start by asking if the Java language designers were too stupid to implement multiple inheritance? Why did the C++ guys implement it then? We mostly land at the Diamond Anti-Pattern then:
In object-oriented programming languages with multiple inheritance and knowledge organization, the diamond problem is an ambiguity that arises when two classes B and C inherit from A, and class D inherits from both B and C. If a method in D calls a method defined in A (and does not override the method), and B and C have overridden that method differently, then from which class does it inherit: B, or C?
The other way to explore is how Java “emulates” multiple inheritance? The answer, which might already have surfaced, ist Interfaces. We then usually discuss interfaces in Java, if, when and how the candidate has used them in the past. What are interfaces good for, does he like them? I can explore how good he is at modelling and sometimes make him draw a diagram with interfaces. We go on with problems of interfaces in Java, and what happens when two interfaces have the same static fields and a class implements both – some kind of “multiple inheritance” in Java:
public interface I1 {
String NAME = "codemonkeyism";
}
public interface I2 {
String NAME = "stephan";
}
public class C implements I1, I2 {
public static void main(String[] args) {
System.out.println(NAME);
}
}
Staying true, the language designer decided that this does not work in Java:
C.java:3: reference to NAME is ambiguous, both variable NAME
in I1 and variable NAME in I2 match
System.out.println(NAME);
^
1 error
There are many more ways to explore with the candidate, e.g. what are the modifiers of interface methods. Are mixins or traits a better solution to the diamand problem than interfaces? Or are they just as bad as multiple inheritance? As I’m no longer very fond of inheritance and think most uses are a code smell, one can also discuss the down side of inheritance – thight coupling for example – with the candidate.
Why?
Why do I ask this question and what do I learn from it? Inheritance is a very basic concept in OO and should be understood by every Java developer. Reflection on his work and going beyond knowing the syntax is an essential trait also, therefor the multiple inheritance question. I prefer questions that spawn many opportunities to explore. The inheritance question is one of them: Mutliple inheritance, language design, code smells, solutions, interfaces, role based development.
I would like to add something to the previous answer.
As you understood from the deep explanation given by Tilsan The Fighter multiple inheritance is not supported by Java.
Alternatively you should use one of delegation design patterns. I know that sometimes the code looks more verbose than code done using multiple inheritance but this is the price we have to pay.
You asked a question why do you need to create class that implements more than one interface? I'd ask you a question why do you need interface at all? I think that the answer is that this allows you to separate interface (contract) from concrete implementation, make modules independent, simplify re-factoring and make programs more flexible: you can switch implementations only if the concrete implementation is hidden by interface.
If your class can be used in different contexts as A and as B (where A and B are interfaces) the class should implement 2 interfaces.
Example: Let's assume that you have a business interface Foo that declares only one method
int foo(String str);
Now you create a couple of classes A and B that implement Foo:
public class A implements Foo {
public int foo(String s) {
return s.length();
}
}
public class B implements Foo {
public int foo(String s) {
return s.hashCode();
}
}
Now you would like to create collection of Foo:
Collection<Foo> collection = new ArrayList<Foo>();
collection.add(new A());
collection.add(new B());
Code that uses this collection does not know anything about the concrete implementation but it does not bother it to invoke foo().
Now you wish to sort this collection. One of the ways is to implement yet another interface Comparable:
public class A implements Foo, Comparable<Foo> {
public int foo(String s) {
return s.length();
}
public int compareTo(Foo o) {
return getClass().getName().compareTo(o.getClass().getName());
}
}
Once you are done you can say:
Collections.sort(collection);
And the collection will be sorted according to the rule defined in compareTo().
Now you probably wish to serialize the instances of A and B. To do this you have to implement yet another interface Serializable. Fortunately Serializable is a special interface that does not declare any method. JVM knows to serialize and desirialize objects that are instances of Serializable.
public class A implements Foo, Comparable<Foo>, Serializable {
public int foo(String s) {
return s.length();
}
public int compareTo(Foo o) {
return getClass().getName().compareTo(o.getClass().getName());
}
}
Class B looks the same.
Now we can say:
DataOutputStream os = new DataOutputStream(new FileOutputStream("/tmp/foo.dat"));
os.writeObject(new A());
os.writeObject(new B());
os.flush();
os.close();
and store our objects in file /tmp/foo.dat. We can read the objects later.
I tried to show why do we need classes that implement several interfaces: each interface gives the class its behavior. Comparable allows sorting collection of such instances. Serializable allows serialization etc.
Does something like this make any sense at all in Java?
class A<T extends B> extends T{
int fun1() {
....
}
}
abstract class B extends X implements C {
}
interface C {
int fun1();
}
I want class B to extend both X and C ideally. But since there is no multiple inheritance in Java, I'm trying to come up with a slicker workaround.
The trick is that the stuff that would be defined in C is defined in Super Class "A" instead. The problem is to get A let me use a generic type after "extends"
Thoughts?
No, you can't make a type extend a class specified as a type parameter
Without knowing what A, B, C or X are, it's very hard to recommend an alternative design pattern I'm afraid.
What you're trying to do is not going to work - Java generics have nothing to do with inheritance. There is no multiple inheritance, you'll have to make your peace with that :-)
You can declare multiple interfaces and use aggregation to "fake" multiple inheritance.
As others have said, generics won't help you with multiple inheritance of implementations.
My workaround for not repeating myself due to multiple inheritance is usually to write the common implementation in a static method in the superclass, and delegate to that from the places where it is needed.
The simplest example would be like this:
class A
{
}
class B extends A
{
}
interface C
{
void foo();
}
class CBase extends A implements C
{
public void foo()
{
sFoo(this);
}
static void sFoo(C c)
{
// Implement foo here
}
}
class D extends B implements C
{
public void foo()
{
CBase.sFoo(this);
}
}
Note that to make this useful there would be more operations inherited by D from B and A, which are not shown in this example.
The type parameter is only a placeholder for the compile-time-only generics, it is an actual type.
Trying to come up with a workaround solution for multiple inheritance in a language that does not support it is probably a good indicator that the flaw is in the design. Saying A<T extends B> extends T will obviously fail as it doesn't even mean what you're hoping it to mean - <T extends B> means only that T is of a type that is a B. Appending extends T does not mean anything because T is not defined in that class. Again, this is a compile-time type - the actual type of T is not directly available during runtime.
Are you really sure that what is most properly achieved via multiple inheritance as opposed to composition? It could also be possible that you're trying to get A to do too many things.
A more concrete example might allow others to give more feedback on the design itself.