Develop Reference

How interfaces in java used for code reuse? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 5 years ago.
Improve this question
I am learning java, and came to know that Java doesn't support multiple inheritance. So, java introduced interfaces for that. How does the problem of multiple inheritance is solved by interface?
What I read online : "Inheritance in java means code reuse".
If i implement an interface in class say A, I will have to give my own implementation for it in A, and same in B, which means methods in interface (say I) will have different implementation in A and B. How does it use the code re-usability feature?

You haven't given proper citations for any of the assertions that you make in your Question, so it is impossible to know what they are actually saying ... or why you think that they are say these incorrect or misleading things.
I am learning java, and came to know that Java doesn't support multiple inheritance.
That is correct.
So, java introduced interfaces for that.
That is INCORRECT. Java introduced interfaces to support polymorphism. Specifically polymorphism that does not depend on class inheritance.
How does the problem of multiple inheritance is solved by interface?
It isn't.
Multiple inheritances are about inheritance of method and field declarations from multiple parent classes. Interfaces does not provide that, and it does not solve the problem.
Interfaces do allow you to declare a common API (or APIS) and implement that API without necessarily sharing code. But with careful design you can do code-sharing under the hood any; e.g. by using the Delegation design pattern.
What I read online : "Inheritance in java means code reuse".
I doubt that what it actually said. Anyway, it is INCORRECT.
Inheritance (of classes) is one way to achieve code reuse, but it is only one of many ways to achieve reuse. There are many others.
If i implement an interface in class say A, I will have to give my own implementation for it in A, and same in B, which means methods in interface (say I) will have different implementation in A and B.
I presume that you mean something like this:
public interface I {
void someMethod();
}
public class A implements I {
void someMethod() {
// some code
}
}
public class B implements I {
void someMethod() {
// some code
}
}
How does it use the code re-usability feature?
There is no code reuse in that example. But this is not inheritance of classes (which I described as one way to achieve code reuse). It is a class implementing an interface.
(Now in Java 8, you can put code into interfaces in certain circumstances; read up on the default methods feature. And that does allow direct code reuse via an interface. But I doubt that is what the sources you have been looking at are talking about.)

Java solved the problem of multiple inheritance (or rather the problems that come with this feature) by allowing single inheritance, that is allowing only one super class. This design created a new problem of a class that needs to implement multiple contracts. a contract, like is explained in #Kermi's answer, allows other objects to refer to the same Object as different types, for various purposes, the most common one is for storing in Collections. an interface can be regarded as a super class that has no implementation (all the methods are pure virtual if you like)
So, Java removed the problems that come with multiple inheritance (the famous diamond problem) but also the advantages that come with it such as code reusability. This design follows the principal of making Java simple and easy and predictable by removing "advanced" (some say confusing) C++ features like multiple inheritance, operator overloading, pointer manipulation (among others).
There are several technics that allow Java to restore most of the code reusability of multiple inheritance. One such technic is composition: so if we take #Kermi's example, you can have a GeneralAnimal class that implements the most common behavior of an Animal. every Dog instance holds a reference to a GeneralAnimal instance (obtained through ctor or factory or dependency injection or ...) and can delegate some messages (=method calls) to that instance. The same is done in Cat instances and so on.

Interface doesn't resolve multiple inheritance problem or rather it doesn't create a multiple inheritance problem. It gives you a possibility to reuse existing implementations.
For example:
class Dog implements Comparable<Dog>, Animal
As your class implements 2 interfaces you can use them in difeerent ways. To use TreeSet object needs to implement Comparable methods (it is not the only possibility). When Dog is passed to TreeSet implementation of that structure is then sure that object has compareTo(Dog dog) method and can use it.
But than you want to store a List of Animals, and than iterate through that list with execution method declared for Animal, than you would not use Comparable interface, but Animal.
List<Animals> animals = new ArrayList<>();
animals.add(dog);
animals.add(cat);
for (Animal animal : animals) {
animal.walk();
}

Interface is a criterion, I think.
A and B should conform to it. In addition, A and B do different things such as ArrayList and LinkedList.
"Inheritance in java means code reuse" is right, but Interface is not. It embodies a norm.
When you learn Collections, you will understand it clearly.

Multiple Inheritance :Java vs C++

Recently ,after reading some articles in Programming Languages and Practice book ,it is mentioned that multiple interface inheritance in Java does not suffer from the same problems as multiple class inheritance in C++.
But I can't understand why this happens. How java is able to use multiple interface inheritance while in C++ implementation errors exists ??
Is there a way to replace multiple inheritance in C++ as to avoid implementation problems ??
For the last statement to be more specific ,lets say that we have:
class A {...};
class B : public A {...};
class C : public A {...};
class D : public B, public C {...};
Then class D inherits class B,C which both inherit class A. So if A had a field-variable then B,C would have the same variable name ,then what variable would D has (inherited from B or C) .To avoid this could we write the above code without multiple inheritance but with similar results?
The question is not a duplicate since it is not focused on what finally will be the inheritance in the example ,but to understand the difference between Java-C++ multiple inheritance(see the first question above) and also if there is a way suggested to overcome some multiple inheritance problems (like the above).

Java (unlike C++) does not allow multiple inheritance of state and, therefore, does not suffer from a diamond problem.
It allows multiple inheritance of type through interfaces (a class can implement multiple interfaces).
Starting with Java 8 there is also multiple inheritance of behavior through default methods in interfaces.

But I can't understand why this happens. How java is able to use multiple interface inheritance while in C++ implementation errors exists???
That is possible because Java does not allow multiple inheritance, but only multiple implementation from multiple interface.
Implementation is different than inheritance.
The general problem with multiple inheritance is (in short) that two classes may define different ways of doing the same thing, and the subclass can't choose which one to pick.
Since interface in java can only declare the signature of methods without implementing them, the problem does not exists if multiple interface are derived.
In conclusion, in order to avoid the problem Java forbids directly multiple inheritance, and allows only multiple implementation of interface.
Is there a way to replace multiple inheritance in c++ as to avoid implementation problems???
The first suggest I can give you is to avoid a design so complex.
Anyway the problem you've exposed in your question is very common and known as diamond problem.
C++ provides a solution in order to solve that problem with the usage of virtual inheritance.
Let an inheritance graph:
A
/ \
B C
\ /
D
This is the problem:
C++ by default follows each inheritance path separately, so a D object would actually contain two separate A objects, and uses of A's members have to be properly qualified.
And this is a briefly explanation about the virtual inheritance:
If the inheritance from A to B and the inheritance from A to C are both marked "virtual" (for example, "class B : virtual public A"), C++ takes special care to only create one A object, and uses of A's members work correctly. If virtual inheritance and nonvirtual inheritance are mixed, there is a single virtual A and a nonvirtual A for each nonvirtual inheritance path to A.
In short, with virtual inheritance you prevent the part class A is duplicate in the class D.

To avoid this could we write the above code without multiple inheritance but with similar results?
It follows a minimal, working example:
struct A {};
struct B {};
struct C {};
struct D {
operator A&() { return a; }
operator B&() { return b; }
operator C&() { return c; }
private:
A a;
B b;
C c;
};
void f(const B &b) {}
int main() {
D d;
f(d);
}
If you don't want to create an explicit hierarchy, but still you would like to use an instance of D where a reference to B is required, the solution above works just well.
It is based on composition instead of inheritance, as you can see.
It has some limits, of course, as an example you cannot cast a pointer to D to a pointer to B.
If it fits your requirements mostly depends on the real problem, so I cannot say.
Anyway, that's is a viable solution somehow similar to the inner class idiom, if you are interested in having further details.

The "multiple inheritance" in Java is no real multiple inheritance. Since Java can only create the diamond problem by using interfaces.
Interfaces are only a reference to an implemented method in the sub class, because an interface cannot implement a method.
So the child class cannot have parents with different implementions. It doesn't matter from which interface you inherit the method, since no implementation exists.
Edit: oh I forgot how Java destroyed the principle behind interfaces by introducing default methods...

Why is the diamond case with its common ancestor used to explain Java multiple inheritance issue, instead of two unrelated parent classes?

This question might sound weird to Java people but if you try to explain this, it would be great.
In these days I am clearing some of Java's very basic concept.
So I come to Inheritance and Interface topic of Java.
While reading this I found that Java does not support Multiple Inheritance and also understood that, what I am not able to understand that why everywhere Diamond figure issue(At least 4 class to create diamond) is discussed to explain this behavior, Can't we understand this issue using 3 classes only.
Say, I have class A and class B, these two classes are different (they are not child class of common class) but they have one common method and they look like :-
class A {
void add(int a, int b) {
}
}
class B {
void add(int a, int b) {
}
}
Ok,Now say if Java supports Multiple inheritance and if there is one class which is the subclass of A and B like this :-
class C extends A,B{ //If this was possible
#Override
void add(int a, int b) {
// TODO Auto-generated method stub
super.add(a, b); //Which version of this, from A or B ?
}
}
then compiler will not be able to find which method to call whether from A or B and that is why Java does not support Multiple Inheritance. So is there any thing wrong with this concept ?
When I read about this topic I was able to understand Diamond issue, but I am not able to understand why people are not giving example with three class (If this is valid one, because we used only 3 classes to demonstrate issue so its easy to understand by comparing it to Diamond issue.)
Let me know whether this example does not fit to explain issue or this can also be referred to understand issue.
Edit:
I got one close vote here stating that question is not clear.
Here is main question :-
Can I understand Why "Java does not support Multiple Inheritance" with 3 classes only as described above or I must need to have 4 classes (Diamond structure) to understand the issue.

The problem with diamond inheritance is not so much shared behaviour but shared state. As you can see, Java in fact has always supported multiple inheritance, but only multiple inheritance of type.
With only three classes the problem is resolved relatively easily by introducing a simple construct like super.A or super.B. And while you're only looking at overridden methods, it indeed doesn't matter whether you have a common ancestor or just the basic three classes.
However if A and B have a common ancestor, the state of which they both inherit, then you're in serious trouble. Do you store two separate copies of the state of this common ancestor? That would be more like composition than inheritance. Or do you only store one that is shared by both A and B, causing strange interactions when they manipulate their inherited shared state?
class A {
protected int foo;
}
class B extends A {
public B() {
this.foo = 42;
}
}
class C extends A {
public C() {
this.foo = 0xf00;
}
}
class D extends B,C {
public D() {
System.out.println( "Foo is: "+foo ); //Now what?
}
}
Note how the above wouldn't be so big a problem if class A didn't exist and both B and C declared their own foo field. There would still be a problem of clashing names, but that could be resolved with some namespacing construct (B.this.foo and C.this.foo maybe, as we do with inner classes?). The true diamond problem on the other hand is more than a naming clash, it's a matter of how to maintain class invariants when two unrelated superclasses of D (B and C) share the same state they both inherit from A. This is why all four classes are needed to demonstrate the full extent of the problem.
Shared behaviour in multiple inheritance doesn't exhibit the same problem. So much so that the recently introduced default methods do exactly that. This means that multiple inheritance of implementations is allowed now too. There is still some complication around the resolution of which implementation to call but since interfaces are stateless, the biggest bugbear is avoided.

Java does not support multiple inheritance because the designers of the language designed Java this way. Other languages like C++ support multiple inheritance just fine, so it is not a technical issue but just a design criteria.
The problem with multiple inheritance is that it is not always clear which method from which class you are calling to, and which instance variables you are accessing to. Different people interpret it differently and the Java designers believed at that time that it was better to skip multiple inheritance altogether.
C++ solves the diamond shaped class issue with virtual inheritance:
Virtual inheritance is a technique used in object-oriented
programming, where a particular base class in an inheritance hierarchy
is declared to share its member data instances with any other
inclusions of that same base in further derived classes. For example,
if class A is normally (non-virtually) derived from class X (assumed
to contain data members), and class B likewise, and class C inherits
from both classes A and B, it will contain two sets of the data
members associated with class X (accessible independently, often with
suitable disambiguating qualifiers). But if class A is virtually
derived from class X instead, then objects of class C will contain
only one set of the data members from class X. The best-known language
that implements this feature is C++.
Contrary to Java, in C++ you can disambiguate which instance method to call by prefixing the call with the name of the class:
class X {
public: virtual void f() {
}
};
class Y : public X {
public: virtual void f() {
}
};
class Z : public Y {
public: virtual void f() {
X::f();
}
};

That is just one difficulty that you have to solve for multiple inheritance in a language. Since there exist languages that do have multiple inhertance (e.g. Common Lisp, C++, Eiffel), it is obviously not insurmountable.
Common Lisp defines the exact strategy for priorizing (ordering) the inheritance graph, so there is no ambiguity in the rare cases where it does matter in practice.
C++ uses virtual inheritance (I have not yet put the effort in to understand what that means).
Eiffel allows to specify exactly how you want to inherit, possibly renaming methods in the subclass.
Java just skipped multiple inheritance. (I personally think that it is difficult not to be insulting to its designers while trying to rationalize this decision. Of course, it is hard to think about a thing when the language you think in does not support it.)

The diamond problem with four classes is simpler than three classes problem described in the question.
The problem with three classes adds another issue that has to be solved first: The naming conflict caused by two unrelated add methods with the same signature. It's not actually hard to solve but it adds unnecessary complexity. It would probably be allowed in Java (like it is already allowed to implement multiple unrelated interface methods with the same signature), but there could be languages that simply prohibit multiple inheritance of similar methods without a common ancestor.
By adding a fourth class which defines add, it is clear that both A and B are implementing the same add method.
So the diamond problem is more clear because it shows the problem using simple inheritance instead of just using methods with the same signature. It is well known and probably applies to a wider range of programming languages, so the variation of it with three classes (which adds the additional naming conflict issue) doesn't make much sense and therefore hasn't been adopted.

Multiple inheritance is no problem if you find a sane solution to method resolution. When you invoke a method on an object, method resolution is the act of picking which class'es version of the method should be used. For this, the inheritance graph is linearized. Then, the first class in this sequence that provides an implementation of the requested method is chosen.
To illustrate the following examples of conflict resolution strategies, we will be using this diamond inheritance graph:
+-----+
| A |
|=====|
|foo()|
+-----+
^
|
+---+---+
| |
+-----+ +-----+
| B | | C |
|=====| |=====|
|foo()| |foo()|
+-----+ +-----+
^ ^
| |
+---+---+
|
+-----+
| D |
|=====|
+-----+
The most flexible strategy is requiring the programmer to explicitly choose the implementation when creating an ambiguous class, by explicitly overriding the conflicting method. A variant of this is banning multiple inheritance. If a programmer wants to inherit behaviour from multiple classes, composition will have to be used, and a number of proxy methods to be written. However, naively explicitly resolved inheritance conflicts has the same shortcomings as…
Depth first search, which might create the linearization D, B, A, C. But this way, A::foo() is considered before C::foo() although C::foo() overrides A::foo()! This can't be what we wanted. An example of a language using DFS is Perl.
Use a clever algorithm that guarantees that if X is a subclass of Y, it will always come before Y in the linearization. Such an algorithm will not be able to unravel all inheritance graphs, but it provides sane semantics in most cases: If a class overrides a method, it will always be preferred over the overridden method. This algorithm exists and is called C3. This would create the linearization D, B, C, A. C3 was first presented in 1996. Unfortunately, Java was published in 1995 – so C3 was not known when Java was initially designed.
Use composition, not inheritance – revisited. Some solutions to multiple inheritance suggest getting rid of the “class inheritance” bit, and instead propose other units of composition. One example is mixins, which “copy & paste” method definitions into your class. This is incredibly crude.
The idea of mixins has been refined into traits (presented 2002, also too late for Java). Traits are a more general case of both classes and interfaces. When you “inherit” a trait, the definitions are embedded into your class, so that this does not complicate method resolution. Unlike mixins, traits provide more nuanced strategies to resolve conflicts. Especially, the order in which traits are composed matters. Traits play a prominent role in Perl's “Moose” object system (called roles) and in Scala.
Java prefers single inheritance for another reason: If each class can only have one superclass, we don't have to apply complicated method resolution algorithms – the inheritance chain already is the method resolution order. This makes methods a bit more efficient.
Java 8 introduced default methods which look similar to traits. However, the rules of Java's method resolution make interfaces with default methods much less capable than traits. Still, a step in the direction of adapting modern solutions to the multiple-inheritance problem.
In most multiple inheritance method resolution schemes, the order of superclasses does matter. That is, there's a difference between class D extends B, C and class D extends C, B. Because the order can be used for simple disambiguation, a three-class example does not sufficiently demonstrate the problems associated with multiple inheritance. You need a full four-class diamond problem for that, as it shows how naive depth-first search leads to an unintuitive method resolution order.

The diamond problem that you cite is one reason (and a very good one) not to support multiple inheritance. There are other reasons too, which you can read a bit about here.
A lot of the reasons boil down to complexity (it's quite complex to do it right), the relatively rare legitimate need to use it, and all sorts of other problems with dispatching (aside from just the diamond problem) that it creates.

why multiple inheritances are not possible in java [duplicate]

This question already has answers here:
Why is Multiple Inheritance not allowed in Java or C#?
(17 answers)
Java Multiple Inheritance
(17 answers)
Closed 8 years ago.
"Why multiple inheritance is not possible in java ?" is any different to the question
"Why multiple inheritance is not supported in java ?" or both are inter related .
I know this has already been answered , just looking for a difference if any not the answer to the why.

Both are same question.
If it is possible, we may end up with famous Diamond death problem.
The reason that Java's creators chose not to allow multiple inheritance is that it can become quite messy.
In a nutshell, the problem is that if a class extended two other classes, and both superclasses had, say, a doStuff() method, which version of doStuff() would the subclass inherit?This issue can lead to a scenario known as the "Deadly Diamond of Death,"
Because of the shape of the class diagram that can be created in a multiple inheritance design. The diamond is formed when classes B and C both extend A, and both B and C inherit a method from A. If class D extends both B and C, and both B and C have overridden the method in A, class D has, in theory, inherited two different implementations of the same method. Drawn as a class diagram, the shape of the four classes looks like a diamond."
So in Java for simplicity, you have one and only one base class. Searching for the base class is a linear search from top to bottom, simple, fast and efficient.
But multiple inheritance is useful, it's conceivable that the same class may want to represent itself differently to different clients. That is done by using interfaces. An interface is just like a base class, but carries no data and no methods.
When you implement an interface you have to supply all the members it needs, which is simple to understand. When the computer casts to the interface all it needs to do is start from the type object and search upwards through the base classes looking for one that implements the interface.
Interfaces do 95% of the work multiple inheritance for 10% of the brain space and 15% of the CPU space. The 5% that interfaces can't do that multiple inheritance can may be simply implemented by composition.
That is why its not supported.

Java - what is a a prototype?

In a lecture on Java, a computer science professor states that Java interfaces of a class are prototypes for public methods, plus descriptions of their behaviors.
(Source https://www.youtube.com/watch?v=-c4I3gFYe3w #8:47)
And at 8:13 in the video he says go to discussion section with teaching assistants to learn what he means by prototype.
What does "prototype" mean in Java in the above context?

I think the use of the word prototype in this context is unfortunate, some languages like JavaScript use something called prototypical inheritance which is totally different than what is being discussed in the lecture. I think the word 'contract' would be more appropriate. A Java interface is a language feature that allows the author of a class to declare that any concrete implementations of that class will provide implementations of all methods declared in any interfaces they implement.
It is used to allow Java classes to form several is-a relationships without resorting to multiple inheritance (not allowed in Java). You could have a Car class the inherits from a Vehicle class but implements a Product interface, therefor the Car is both a Vehicle and a Product.

What does "prototype" mean in Java in the above context?
The word "prototype" is not standard Java terminology. It is not used in the JLS, and it is not mentioned in the Java Tutorial Glossary. In short there is no Java specific meaning.
Your lecturer is using this word in a broader sense rather than a Java-specific sense. In fact, his usage matches "function prototype" as described in this Wikipedia page.
Unfortunately, the "IT English" language is full of examples where a word or phrase means different (and sometimes contradictory) things in different contexts. There are other meanings for "template" that you will come across in IT. For instance:
In C++ "template" refers to what Java calls a generic class or method.
In Javascript, an object has a "template" attribute that gives the objects methods.
More generally, template-based typing is an alternative (more dynamic) way of doing OO typing.
But the fact that these meanings exist does not mean that your lecturer was wrong to refer to interface method signatures as "templates".

"prototype" is not the the best/right terminus to be used. interfaces are more like "contracts", that implementing classes have to fulfill.
The method's heads/definitions will have to be implemented in the implementing class (using implements keyword in the class head/class definition/public class xy implements ...).
I guess this naming conventions leave much room for many ideological debates.
Or the author had some sort of a mental lapsus and mapped the construct of prototypical inheritance from javascript into java in his mind somehow.

Interfaces are not prototypes for classes in Java.
In languages like C & C++, which compiles to machine code sirectly, compiler should be aware of the nature of any identifier (variable/class/functions) before they are references anywhere in the program. That mean those languages require to know the nature of the identifier to generate a machine code output that is related to it.
In simple words, C++ compiler should be aware of methods and member of a class before that class is used anywhere in the code. To accomplish that, you should define the class before the code line where it is used, or you should at least declare its nature. Declaring only the nature of a function or a class creates a 'prototype'.
In Java, an 'interface' is something like description of a class. This defines what all methods a particular kind of class should mandatory have. You can then create classes that implements those interface. Main purpose that interfaces serve in java is the possibility that a Variable declared as of a particular interface type can hold objects of any class that implements the object.

He tells it in C/C++ way, let me explain, in C++ you can define prototypes for methods at the header files of classes so that other classes can recognize these methods, also in C where there is no class concept, you can define prototypes at the beginning of file and then at somewhere in same file you can implement these prototypes, so that methods can be used even before their implementation is provided. So in Java interfaces provide pretty much same way, you can define prototypes for methods(method headers) that will be implemented by classes that implement this interface.

In a lecture on Java, a computer science professor states that:
Java interfaces of a class are:
1. are prototypes for public methods,
2. plus descriptions of their behaviors.
For 1. Is ok: - yes, they are prototypes for implemented public methods of a class.
For 2. This part could be a little bit tricky. :)
why?
we know: interface definition (contain prototypes), but doesn't define (describe) methods behavior.
computer science professor states: "... plus descriptions of their behaviors.". This is correct only if we look inside class that implements that interface (interface implementation = prototype definitions or descriptions).
Yes, a little bit tricky to understand :)
Bibliography:
Definition vs Description
Context-dependent
Name visibility - C++ Tutorials
ExtraWork:
Note: not tested, just thinking! :)
C++:
// C++ namespace just with prototypes:
// could be used like interface similar with Java?
// hm, could we then define (describe) prototypes?
// could we then inherit namespace? :)
namespace anIntf{
void politeHello(char *msg);
void bigThankYou();
}

Prototypes provide the signatures of the functions you will use
within your code. They are somewhat optional, if you can order
your code such that you only use functions that are previously
defined then you can get away without defining them
Below a prototype for a function that sums two integers is given.
int add(int a, int b);

I found this question because i have the same impression as that teacher.
In early C (and C++ i think) a function, for example "a" (something around lexic analysis or syntactic, whatever) can not be called, for example inside main, before it's declaration, because the compiler doesn't know it (yet).
The way to solve it was, either to declare it before it's usage (before main in the example), or to create a prototype of it (before main in the example) which just specifies the name, return values and parameters; but not the code of the function itself, leaving this last one for wherever now is placed even after it's called.
These prototypes are basically the contents of the include (.h) files
So I think is a way to understand interfaces or the way they say in java "a contract" which states the "header" but not the real body, in this case of a class or methods