• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

Why do we need interfaces?

 
Greenhorn
Posts: 1
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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). 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 ? Since all the method inside the interface requires to implement it inside the class that implement the Interface. Do you think that there is redundancy factor arises because in class the same method and in interface the same method (Description only).

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.

for example
 
Bartender
Posts: 6109
6
Android IntelliJ IDE Java
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator

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.
     
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Basic Java interface question:

    Why do Java API interfaces have defined methods?
    Or is it just defining the contract that the implementing class must follow?

    So if I have a reference to the ResultSet interface (i.e. rs) and I call the method rs.next() I am really making an interface reference to the implementing class of the ResultSet interface which has implemented the next() method?

    What if there are multiple implementation classes for an interface, if I use an interface reference won't there be a conflict as to which implementing classes method to use?
     
    Bartender
    Posts: 10780
    71
    Hibernate Eclipse IDE Ubuntu
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Mitch Young wrote:Why do Java API interfaces have defined methods?


    They don't; at least, not ALL of them do. A few examples that don't:
    RandomAccess, Serializable, Cloneable.
    Although arguably the last two (particularly the last) should have.

    Or is it just defining the contract that the implementing class must follow?
    So if I have a reference to the ResultSet interface (i.e. rs) and I call the method rs.next() I am really making an interface reference to the implementing class of the ResultSet interface which has implemented the next() method?


    Yup and yup.

    What if there are multiple implementation classes for an interface, if I use an interface reference won't there be a conflict as to which implementing classes method to use?


    Nope. And furthermore, as Jeff said, if you are a user of the reference, you don't care what the actual class is.

    The easiest example I know is:
    List<String> myList = new LinkedList<String>();

    I've just defined a List that is implemented with an LinkedList.

    Now what if, a few months down the road, I decide that my program/class would be much better off if it used an ArrayList instead?
    Providing I only ever expose the interface to clients, I simply change that line to:
    List<String> myList = new ArrayList<String>();
    and now my class runs a lot faster.

    HIH

    Winston
     
    Jeff Verdegan
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Mitch Young wrote:
    What if there are multiple implementation classes for an interface, if I use an interface reference won't there be a conflict as to which implementing classes method to use?



    No, because even though multiple implementing classes exist, by the time you're using a variable of the interface type, it's been assigned a reference that points to a single instance of a single concrete implementation. It's just like any other variable. Winston showed you an example with List. With the JDBC interfaces is will be something like this.



    and so on.
     
    Mitch Young
    Greenhorn
    Posts: 10
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator
    Thanks Winston and Jeff.

    Just to be clear, if there were more than one class that implemented ResultSet then one would not be able to make this reference: ResultSet rs; ?
    Thanks again.
     
    Jeff Verdegan
    Bartender
    Posts: 6109
    6
    Android IntelliJ IDE Java
    • Likes 1
    • Mark post as helpful
    • send pies
      Number of slices to send:
      Optional 'thank-you' note:
    • Quote
    • Report post to moderator

    Mitch Young wrote:Thanks Winston and Jeff.

    Just to be clear, if there were more than one class that implemented ResultSet then one would not be able to make this reference: ResultSet rs; ?
    Thanks again.



    No, that is absolutely not true, and it goes directly against what I just walked through above.

    When we do ResultSet rs, all we're doing is saying, "There is a variable called rs, and it will point to an object that IS-A ResultSet." At that point, neither the compiler nor the JVM cares how many classes it currently knows about that fit that requirement. It could be zero, one, or many. It does not create any object, and it does not require any concrete implementation to even exist. It's just a reference that can at some point refer to an instance of a concrete implementation class.

    At some point--either on that same line or elsewhere in the code--there will be rs = something. That something will be an expression that evaluates to a reference to a concrete class that implements ResultSet. It might have come from a driver doing new MyConcreteResultSet() or from MyConcreteResultSet.newInstance() or whatever, but somewhere, something is creating an instance of a concrete class that implements ResultSet.

    Doing ResultSet rs is no different from doing Object ob in this respect. There's no problem with the fact that there are thousands of classes that are suptypes of Object, just as there's no problem with the fact that there may be multiple classes that are subtypes of ResultSet.
     
    Consider Paul's rocket mass heater.
    reply
      Bookmark Topic Watch Topic
    • New Topic