Win a copy of Zero to AI - A non-technical, hype-free guide to prospering in the AI era this week in the Artificial Intelligence and Machine Learning forum!
  • 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 all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Liutauras Vilda
  • Paul Clapham
  • Bear Bibeault
  • Jeanne Boyarsky
Sheriffs:
  • Ron McLeod
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Tim Moores
  • Tim Holloway
  • Jj Roberts
  • Stephan van Hulst
  • Carey Brown
Bartenders:
  • salvin francis
  • Scott Selikoff
  • fred rosenberger

How exactly can the interface be used to hide the implementation from the client?

 
Ranch Foreman
Posts: 1770
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I have read that interface can be used to hide the implementation from client . I want to  understand how exactly can it hide the implementation from the client.

Thanks
 
Saloon Keeper
Posts: 6625
161
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Somewwhat like this. myMethod never knows what kind of List it gets, just that it does, in fact, get a List.

 
Monica Shiralkar
Ranch Foreman
Posts: 1770
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks.

But myMethod is not the client. The client would be where this myMethod call is taking place .
 
Tim Moores
Saloon Keeper
Posts: 6625
161
Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I see. Then it would be more like this:
 
Monica Shiralkar
Ranch Foreman
Posts: 1770
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks. Based on that I wrote a code to understand this .




I am trying to understand that what exactly have we been able to hide. Only the names of methods : getAnimal or getPig/getDog?
 
Saloon Keeper
Posts: 22634
153
Android Eclipse IDE Tomcat Server Redhat Java Linux
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Also see Here.
 
Sheriff
Posts: 15913
265
Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Re "hiding the implementation" -- it simply means that the client would have no idea exactly how something is done. Take for example a method of an interface like List. The client code doesn't know or care about how the add() method would be implemented. All the client cares is that an element will in fact be added to the list when this method is invoked. How that happens exactly will be up to whatever the author of a particular implementation decides to do.

In short, using interfaces is all about the intent of the client, not the implementation.
 
Monica Shiralkar
Ranch Foreman
Posts: 1770
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Thanks
 
Monica Shiralkar
Ranch Foreman
Posts: 1770
9
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Tim Moores wrote:I see. Then it would be more like this:




But when client will be calling this method getMeAList() then that means he has access to this code and he would be able to see what's inside this method and know whether it is returning an arrayList or a LinkedList. I am trying to understand this.

 
Saloon Keeper
Posts: 12409
269
  • Likes 2
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Your assertion contains two mistakes:

  • Clients are humans.
  • Clients that call a method can also see the implementation of that method.

  • First of all, when we talk about hiding implementation details from a client, by client we usually mean "the calling method". The calling method won't be able to see that the returned list in an ArrayList or LinkedList, unless you explicitly cast the return value first. Most programmers won't do this.

    Secondly, if by 'client' we refer to the human programmer, it's not necessarily so that they can see the implementation of a method even if they can call it. A lot of libraries contain only compiled classes and the source hasn't been publicized. Some API implementations run on a web service, and the client doesn't even have access to the compiled classes.

    The most important point of hiding implementation details is not the hiding itself. Nobody really cares if the calling code knows that it got a LinkedList or an ArrayList. The point is that by using List as the return type, you signal to the caller that whatever the implementation is NOW, they shouldn't rely on this because it could change at any moment.
     
    Tim Holloway
    Saloon Keeper
    Posts: 22634
    153
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I don't have to see inside a method to know whether it's returning a LinkedList or an ArrayList. All I have to do is use the instanceof operator or do class introspection on the returned object.

    The idea between hiding the implementation isn't for trivial stuff like this, it's for things like when you want to provide plug-replaceable interface.

    Let's say I define an Interface named "EmailSender". I'll define two classes that implement that interface: DummyEmailSender and LiveEmailSender.

    I can plug in DummyEmailSender when I'm testing and it might simply log the emails that the user of EmailSender tells it to send. LiveEmailSender, however, would actually send them. To avoid needlesly spamming the world, I'd test using DummyEmailSender.

    Inversion of Control (IoC) frameworks are great for this, since you can swap implementations just by changing the "wiring" without actually having to edit and compile anything.

    Another thing you can do is swap different services to achieve optimal performance for a given workload or to be able to take advantage of extra abilities that certain implmenters might provide. XML parsers created for Java often operate that way.

     
    Marshal
    Posts: 70603
    287
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Wouldn't xyz.getClass() give you that information faster?
     
    Tim Holloway
    Saloon Keeper
    Posts: 22634
    153
    Android Eclipse IDE Tomcat Server Redhat Java Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Campbell Ritchie wrote:Wouldn't xyz.getClass() give you that information faster?



    I lumped that under introspection.

    Practically speaking, though, it's probably more common to use instanceof to see if it's safe to cast to a specific class/interface because you want to take advantage of methods and/or properties that the more general interface doesn't guarantee.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:Your assertion contains two mistakes:

  • Clients are humans.
  • Clients that call a method can also see the implementation of that method.

  • First of all, when we talk about hiding implementation details from a client, by client we usually mean "the calling method". The calling method won't be able to see that the returned list in an ArrayList or LinkedList, unless you explicitly cast the return value first. Most programmers won't do this.

    Secondly, if by 'client' we refer to the human programmer, it's not necessarily so that they can see the implementation of a method even if they can call it. A lot of libraries contain only compiled classes and the source hasn't been publicized. Some API implementations run on a web service, and the client doesn't even have access to the compiled classes.

    The most important point of hiding implementation details is not the hiding itself. Nobody really cares if the calling code knows that it got a LinkedList or an ArrayList. The point is that by using List as the return type, you signal to the caller that whatever the implementation is NOW, they shouldn't rely on this because it could change at any moment.



    Thanks. Does that mean the sole purpose of Abstraction is to reduce complexity of our code by this hiding of implementation complexity at the place of calling ?
     
    Tim Moores
    Saloon Keeper
    Posts: 6625
    161
    Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Does that mean the sole purpose of Abstraction is to reduce complexity of our code by this hiding of implementation complexity at the place of calling?


    No:

    Stephan van Hulst wrote:The point is that by using List as the return type, you signal to the caller that whatever the implementation is NOW, they shouldn't rely on this because it could change at any moment.


    The point is to keep the flexibility to change the implementation later if it ever became advantageous to do so.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks.But the definition says "hiding the implementation details and revealing only the functionality".

    Doesn't this talk about hiding of complexity more than the flexibility reason?
     
    Tim Moores
    Saloon Keeper
    Posts: 6625
    161
    Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    No. Just because client code doesn't know specifics of a called method does not mean the code complexity is reduced.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks.So it is not about complexity .

    Okay, so I think based on this there are 2 things .Firstly ,hiding of implementation and showing only relelavent and Second , the flexibility of changing implementing without caller having to bother.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Tim Moores wrote:Somewwhat like this. myMethod never knows what kind of List it gets, just that it does, in fact, get a List.



    Thanks.Is this an example of Abstraction or instead of Polymorphism ?
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Stephan van Hulst wrote:Your assertion contains two mistakes:
    Clients are humans.
    [.


    Thanks,Yes that was wrong.
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:Is this an example of Abstraction or instead of Polymorphism ?


    They are not mutually exclusive. Polymorphism is one form of abstraction.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Thanks.

    From what I understood, Abstraction is hiding the implementation form caller and revealing only what is required, and polymorphism is using the same type to show different behaviour based on situation.

    So when a List type object refers to ArrayList or LinkedList:

    I understand how it is Abstraction because implementation is hidden from the caller whether it is linked list or arrayList.

    However, I do not understand how it is polymorphism. Polymorphism means same type showing different bevaviour in different situations but here whether it refers to arrayList or LinkedList the behaviour which the caller sees is the same.
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Here's a definition of abstraction: the act of considering something in terms of general qualities, apart from concrete realities, specific objects, or actual instances.

    So, if you have a reference to a "Vehicle", there are certain abstractions related to it:
    1. You can ride it
    2. You can get from point A to point B with it
    3. You have to power it somehow
    4. You have to be able to steer it somehow

    If I have a Car or Motorcycle, I can do all those things. As I said, abstraction and polymorphism are not mutually exclusive. When I steer, I'm somehow affecting the direction of a Vehicle. If I had code that was written as thus:

    The call on line 3 is both abstract and polymorphic, isn't it? So, abstraction is about not caring about the implementation while polymorphism is about using the "steer()" message to achieve a goal differently for whatever type of vehicle I'm dealing with. You might think of abstraction as being more concerned with the API and polymorphism enabling different implementations of the same API.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:Here's a definition of abstraction: the act of considering something in terms of general qualities, apart from concrete realities, specific objects, or actual instances.

    So, if you have a reference to a "Vehicle", there are certain abstractions related to it:
    1. You can ride it
    2. You can get from point A to point B with it
    3. You have to power it somehow
    4. You have to be able to steer it somehow

    If I have a Car or Motorcycle, I can do all those things. As I said, abstraction and polymorphism are not mutually exclusive. When I steer, I'm somehow affecting the direction of a Vehicle. If I had code that was written as thus:

    The call on line 3 is both abstract and polymorphic, isn't it? So, abstraction is about not caring about the implementation while polymorphism is about using the "steer()" message to achieve a goal differently for whatever type of vehicle I'm dealing with. You might think of abstraction as being more concerned with the API and polymorphism enabling different implementations of the same API.



    I understood that point that both are not mutually exclusive.

    Instead my doubt is that when Polymorphism means same type showing different bevaviour in different situations but here whether it refers to arrayList or LinkedList the behaviour which the caller sees is the same.
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:Instead my doubt is that when Polymorphism means same type showing different bevaviour in different situations but here whether it refers to arrayList or LinkedList the behaviour which the caller sees is the same.


    Why would you care? Isn't that the entire point of abstraction/polymorphism? All you need to care about is that you're getting the correct behavior. You shouldn't care what the actual underlying object's actual type is.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:
    Why would you care? Isn't that the entire point of abstraction/polymorphism?



    My doubt is not about care or not care.
    Instead it is about different behaviour or same behaviour.
    (One name and 'different' behaviour is Polymorphism but in LinkedList /arrayList example what the caller sees is 'same' behaviour  ).

     
    Tim Moores
    Saloon Keeper
    Posts: 6625
    161
    Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:polymorphism ... here whether it refers to arrayList or LinkedList the behaviour which the caller sees is the same.


    That's not really what is meant by polymorphism. Polymorphism means the same type can behave differently. But here different types (like ArrayList and LinkedList) behave the same, as far as the client is concerned.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Tim Moores wrote:. Polymorphism means the same type can behave differently. But here different types (like ArrayList and LinkedList) behave the same.



    Yes, so doesn't it mean the behaviour is exactly opposite of polymorphism
     
    Tim Moores
    Saloon Keeper
    Posts: 6625
    161
    Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Pretty much. As Junilu said before, it's a different type of abstraction.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Tim Moores wrote:Pretty much. As Junilu said before, it's a different type of abstraction.



    That's for abstraction. And for polymorphism ?
     
    Tim Moores
    Saloon Keeper
    Posts: 6625
    161
    Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    I don't understand what you're asking.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You had said it's a different type of abstraction. I understood. But my doubt is regarding polymorphism. (How is it a valid case of polymorphism when here behaviour is same instead of different ).
     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:But my doubt is regarding polymorphism. (How is it a valid case of polymorphism when here behaviour is same instead of different ).


    It seems you have a basic misunderstanding of what polymorphism is. "Poly" meaning many, "morphism" meaning forms. So polymorphism means "many forms."

    If you look at the example of List, ArrayList, LinkedList, the List defines the API or the generic behavior to expect from any implementation of List. That's the "abstraction" piece. ArrayList and LinkedList provide different implementations of the same behavior defined by List. That's the polymorphism part. ArrayList and LinkedList are different implementations, i.e., forms, of the same API.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:ArrayList and LinkedList provide different implementations of the same behavior defined by List. That's the polymorphism part.



    Thanks. I was thinking it is different behaviour (instead of different implementations) that means polymorphism. So was thinking that when the caller calls add method on list he sees the same behaviour (irrespective of whether it is arrayList or LinkedList.)..but as you said it is not about behaviour but about different implementations.

     
    Junilu Lacar
    Sheriff
    Posts: 15913
    265
    Mac Android IntelliJ IDE Eclipse IDE Spring Debian Java Ubuntu Linux
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    It's all a matter of perspective. The externally observable behavior or result of different List implementations will be the same. This is in keeping with the Liskov Substitution Principle. However, internally, the implementations do in fact behave differently since they are after all implemented differently.

    If you consider the example of engines, at some level a diesel engine essentially does the same thing a gasoline engine does: it provides power to drive the wheels of a vehicle. However, internally, diesel engines and gasoline engines operate in completely different ways. The same thing goes for ArrayLists and LinkedLists and any other implementation of the List interface.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Junilu Lacar wrote:It's all a matter of perspective. The externally observable behavior or result of different List implementations will be the same. This is in keeping with the Liskov Substitution Principle. However, internally, the implementations do in fact behave differently since they are after all implemented differently.

    If you consider the example of engines, at some level a diesel engine essentially does the same thing a gasoline engine does: it provides power to drive the wheels of a vehicle. However, internally, diesel engines and gasoline engines operate in completely different ways. The same thing goes for ArrayLists and LinkedLists and any other implementation of the List interface.



    Thanks.
    Exactly. That was the mistake I was doing. I was thinking that adding to list (linkedlist/arrayList) is same behaviour. But internally it is different behaviour. Thus it goes with the meaning of polymorphism which means same types shows different behaviour depending upon situation.
     
    Campbell Ritchie
    Marshal
    Posts: 70603
    287
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    And using Engine rather than DieselEngine allows you to rebuild the vehicle to take a different kind of engine. If you specify an implementation, you are stuck with the implementation.
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator


    From what I understood:

    Polymorphism :  one type can show different behaviour based on situation (what is refers).
    Abstraction : the called does not need to bother about the details of implementation. (For e.g Interface type referring to either of its implementation types)

    Advantage of abstraction/polymorphism : tomorrow if the implementation changes it does not bother the caller to do any changes.

    (although both are not mutually exclusive).
     
    Monica Shiralkar
    Ranch Foreman
    Posts: 1770
    9
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Tim Moores wrote:No. Just because client code doesn't know specifics of a called method does not mean the code complexity is reduced.



    But doesn't abstraction reduce the complexity of design too (apart from the advantage that caller doesn't have to bother about change in implementation later on) ?
     
    Tim Moores
    Saloon Keeper
    Posts: 6625
    161
    Android Mac OS X Firefox Browser VI Editor Tomcat Server Safari
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Monica Shiralkar wrote:But doesn't abstraction reduce the complexity of design too?


    I guess you could say that. Although the *task* of design becomes harder (you have to consider the abstraction), the resulting design is cleaner (it has less coupling).
    reply
      Bookmark Topic Watch Topic
    • New Topic