Khalid Mehmood wrote:
I have read all the posts regarding this topic. Most of the People emphasize here that Interfaces provides multiple Inheritance alternative, and few of them says that there are very few stages when multiple inheritance need ( Due to Bad Design you need it).
MI of
implementation, which
Java does not provide, is rarely ever needed, and can be a sign of bad design. MI of
interface is pretty common, and is not necessarily a sign of bad design, although if you find yourself implementing a lot of unrelated interfaces in one class, that class is probably doing to much and should be split up.
But my question is totally different that if we are using interfaces in our code all the methods inside a interface must be implemented by the class that implement the interface then why we need Interface ?
To separate an abstract type's definition from it's implementation.
If I'm using JDBC to interact with a database, I can use Connection, PreparedStatement, and ResultSet in my code (all interfaces) and I don't need to know or care anything about the clases implementing them, other that that they provide the methods I need. I don't even need to know their names. And I can swap any implementations in and out, using different classes, without changing any code. Meanwhile, the JDBC implementors (the DB vendors, usually), can each use their own preferred class hierarchy, naming conventions, and implementation details, as long as they implement those interfaces.
If I'm working with a bunch of objects, I can declare my variable as Collection, List, or Set, depending on my needs, without caring whether I get an ArrayList, LinkedList, HashSet, TreeSet, etc. Do I just need some bunch of objects to process one by one? I can declare it a Collection. Do I care about iteration order matching insertion order? I can declare it a List, but an ArrayList or LinkedList will work just as well. Or any other List implementation. Do I need unique elements? I can use any Set implementation, and I don't care which particular class it is.
If I'm writing a sort routine (such as Collections.sort()), all I care about the objects you provide to me is that they provide a way to compare one to the other and tell me which one is "greater". So you implement the Comparable interface. Your class might be String or Integer or Date or Student or whatever. I don't need to know and I don't care. As long as it provides a compareTo() method that follows the contract according to whichever object is "greater" by your class's semantics, I can sort them for you.
If we need a method inside a class. we can directly implement it inside a class. why we put this method(Description) inside a interface first. We don't need to put it inside a interface. We can directly implement this method inside a class, and this way i think we kicked out the interfaces from OOP.
So, you're convinced that you know more about what's good OO language design than the people who designed Java, some of whom have PhD's in computer science, and all of whom put a lot of thought and effort into the language? You believe that you thought of something they didn't?
Note that I'm not saying that it's impossible for you to have an insight that the designers missed. But when you start thinking that way, it's always wise to add "... or am I missing something?" Because in almost all cases, you are missing something, and the problem lies in your lack of understanding. If you don't include that thought--big and bold--from the beginning, you can end up closing your mind to new ideas. In this case, you could consider, "Maybe they had a good reason to add that apparent redundancy, and maybe it's not redundant after all and provides a benefit that I'm just not seeing yet."
Java would be a much poorer language without interfaces, and OO in general would suffer without the concept, which is kind of a core feature in OO languages.