We Keep Coding

Why do you have to define methods in the class rather than the interface? [duplicate]

This question already has answers here:
What does it mean to "program to an interface"?
(33 answers)
Closed 3 years ago.
So, according to GeeksForGeeks, an interface may have fields and method signatures, but those methods cannot be defined.
A class that implements an interface must then define the body of every method in the interface it implements.
If this is the case, what is the point of the method signatures in the interface? Why not allow oneself wiggle room rather than restricting yourself to have to define methods that you may or may not want to use?

Well, there are two points in that.
First, Java supports an implementation in interfaces. You need to use the default keyword, which is in Java since Java 9 (I am not quite sure about the version number). But, why would you do that?
Interfaces share a common interface for several classes and can therefor be used as data types. You can for example write a method, which needs a parameter of an interface type. Within the method you can then call all the parameters methods, where you know their signature, based on the interface.
The point here is, that interfaces describe common behavior. That is, what interfaces are for!
The difference between (abstract) classes and interfaces is: in (abstract) classes, you define, what you have and what it will look like. Inheritance in this case then is a relation of extension (or spezialization), so you describe it in form of the child IS a parent, but it may have something more. But the IS relation is the basic point.
Interfaces describe the behavior, so a class that implements a interface acts like that interface. LinkedList and ArrayList are quite good examples. Internally they look quite different, but they both store many elements (as hash lists do too). Both classes implement the List interface, because you can both treat them as lists: you can for example iterate over them, which is not the case in hash maps.
Thus, if you want to share common structure and content, use inheritance and maybe abstract classes to group them. If you want to share common behavior, use interfaces, because it doesn't matter, how they look inside, but what you can do with them. So you group it by action.

That's not always true. You can provide a default implementation in the interface:
interface SomeInterface {
default int combine(int a, int b) { return a + b; }
}
Now the method implementing SomeInterface can override combine method, but it doesn't have to. In that case it falls back to the default implementation.

Defining methods in the interface allows you to get all benefits of polymorphism. For example, if you have a List, you don't know what exact implementation of List was used to create it - whether it's ArrayList or LinkedList or something else, but you know that you can, for example, add elements in it and get elements from it, because methods add and get are defined in the List interface.

Java: Why multiple interfaces instead of multiple inheritance? [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicates:
Why does Java allow multiple inheritance from interfaces but not from abstract/concrete classes
Why there is no multiple inheritance in Java, but implementing multiple interfaces is allowed
Instead of inheriting from multiple classes (which Java doesn't allow), why are we told to implement multiple interfaces instead?
Surely the point of inheriting from multiple classes is the inherit their functionality - if you have to manually re-insert functionality (for each class extending a set of interfaces) what's the point of using the interfaces? There's no guarantee that two classes implementing the same set of interfaces will provide the same functionality - or am I missing something?

Multiple inheritance is something that can cause multiple problems.
Interfaces are used to give abilities to instances of the class that implement them. I personally use interfaces with composition(using instance variables that are references to other objects) in order to provide functionality to my class that would otherwise be achieved with multiple inheritance.
In other words my class provides the functionality promised by the interface implemented but internally my class instance uses the instance variable to do the job.
"There's no guarantee that two classes
implementing the same set of
interfaces will provide the same
functionality - or am I missing
something?"
About your statement above:
Each method should adhere to a contract so no matter how you implement it the functionality of the method should always be the same if this is what is supposed to do. If it breaks the contract it means it was implemented wrongly.

multiple inheritance may lead to cyclic inheritance.. to avoid that we are going for interface based inheritance..

You should read about the diamond dependency problem http://en.wikipedia.org/wiki/Diamond_problem and to avoid this Java chose interfaces over extension of multiple classes

When and where should I use an interface [duplicate]

This question already has answers here:
When should I use an interface in java? [closed]
(12 answers)
Closed 9 years ago.
When and where should I use an interface ?

Use an interface when you want to define behavior but not provide an implementation.

When you want to separate what's done (method signature definition) from how it's done (method implementation). This is common when you have operations that might be implemented in different ways, but users would acknowledge a common abstracton for all of them.
See java.util.Collection package for examples. There are several implemetations of the java.util.List interface, but the method signatures are the same.

It is strange nobody mentioned the word "contract" (though the previous answer describes it). See for example:
Java interfaces - What exactly is in the contract?
All classes implementing an interface fulfill that interface's contract. This contract is often the only thing a client needs to know about seemingly different classes.
And of course - polymorphism, which is a very convenient way to deal simultaneously with all classes implementing the interface. You just write code using only one supertype - interface's type.

maybe start here?
The purpose of interfaces continued

Why did Java's designers choose interfaces and single inheritance? [duplicate]

This question already has answers here:
Why is there no multiple inheritance in Java, but implementing multiple interfaces is allowed?
(21 answers)
Closed 9 years ago.
I can make abstract class equivalent to interface by putting all abstract methods within abstract class. Why did Java's designers choose to provide support for interfaces and single inheritance instead of multiple inheritance and abstract classes. What is the advantage?

At least for one reason (besides the conceptual differences between the two): you can implement multiple interfaces but you can only inherit from a single abstract class at most.

Class-based multiple inheritance is not supported by Java. You can only inherit from a single class, but you can implement multiple interfaces.
This becomes handy when you need to treat multiple classes polymorphicly when they have different inheritance trees.

An interface is a contract between a class and its behavior. If a class implements an interface, it MUST provide implementation for the methods specified in the interface. There's a number of things that differentiate the two, however.
Check out the Oracle website for more on the differences between interfaces and abstract classes:
http://download.oracle.com/javase/tutorial/java/IandI/abstract.html

If you have multiple classes and you want to force that there would be some methods that should be common among them, irrespective of their behavior(implementation), Interface does that for you
Interface, is like a contract, which every other class which implements it has to follow

Why does Java allow multiple inheritance from interfaces but not from abstract/concrete classes [duplicate]

This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Why there is no multiple inheritance in Java, but implementing multiple interfaces is allowed
Why Java allows multiple inheritance from interfaces but not from abstract or concrete classes

Multiple inheritance of concrete classes raises a variety of issues.
For example, what if a class inherits two different implementations of the same method from two different base classes?
To avoid these issues, Java doesn't support this feature.
Unlike concrete classes, interfaces cannot have method bodies.
Therefore, none of these issues apply to interfaces.

Because implementing an interface is not inheritance. It simply means that your class will adhere to a predefined contract, typically to provide a set of methods related to a certain functionality. Any class can adhere to many such contracts without conflict (unless two of those interfaces define the same method).
Unlike inheritance, it does not automagically receive attributes or functionality due to a hierarchical relationship with its superclass since no such relationship exists.
Multiple inheritance is basically not allowed in Java or many other OO languages due to the already mentioned Diamond Inheritance problem.

I really don't like the term "inherit" here, it leads to a lot of confusion.
Java only allows interfaces to extend other interfaces, and for classes to implement interfaces.
If you look at an interface as a mathematical set of declarations, then each "extends" merely provides the union of the set from the superinterface and that of the current interface. You are therefore allowed to do multiple "unions".
When you eventually get to a class that implements one or more interfaces, the semantics here are merely that the class must provide implementations for all the methods in the set. A class implementing multiple interfaces could be rewritten as a class implementing a single interface that extends all the above interfaces.
In the case of classes inheriting multiple classes it is not allowed because it leads to a variety of problems, including the diamond problem. For instance, if I have two supertypes with different implementations of the same method signature, which one should be used in the subtype?

To make language simpler and more elegant. C++ allows a lots of stuff, but it's often pain to learn and use. We (me, at least :)) don't want java to be like that.