Can you tell me what is the difference between abstraction and information hiding in software development?
I am confused. Abstraction hides detail implementation and
information hiding abstracts whole details of something.
Update: I found a good answer for these three concepts. See the separate answer below for several citations taken from there.
Go to the source! Grady Booch says (in Object Oriented Analysis and Design, page 49, second edition):
Abstraction and encapsulation are complementary concepts: abstraction
focuses on the observable behavior of an object... encapsulation
focuses upon the implementation that gives rise to this behavior...
encapsulation is most often achieved through information hiding, which
is the process of hiding all of the secrets of object that do not
contribute to its essential characteristics.
In other words: abstraction = the object externally; encapsulation (achieved through information hiding) = the object internally,
Example:
In the .NET Framework, the System.Text.StringBuilder class provides an abstraction over a string buffer. This buffer abstraction lets you work with the buffer without regard for its implementation. Thus, you're able to append strings to the buffer without regard for how the StringBuilder internally keeps track of things such the pointer to the buffer and managing memory when the buffer gets full (which it does with encapsulation via information hiding).
rp
The OP updated his question with several citations that he had found, namely in an article by Edward V. Berard titled, "Abstraction, Encapsulation, and Information Hiding". I am re-posting a slightly expanded and reformatted version of the OP's update, since it should be an answer in its own right.
(All citations are taken from the article mentioned above.)
Abstraction:
"One point of confusion regarding abstraction is its use as both process and an entity. Abstraction, as a process, denotes the extracting of the essential details about an item, or a group of items, while ignoring the inessential details. Abstraction, as an entity, denotes a model, a view, or some other focused representation for an actual item."
Information Hiding:
"Its interface or definition was chosen to reveal as little as possible about its inner workings." — [Parnas, 1972b]
"Abstraction can be […] used as a technique for identifying which information should be hidden."
"Confusion can occur when people fail to distinguish between the hiding of information, and a technique (e.g., abstraction) that is used to help identify which information is to be hidden."
Encapsulation:
"It […] refers to building a capsule, in the case a conceptual barrier, around some collection of things." — [Wirfs-Brock et al, 1990]
"As a process, encapsulation means the act of enclosing one or more items within a […] container. Encapsulation, as an entity, refers to a package or an enclosure that holds (contains, encloses) one or more items."
"If encapsulation was 'the same thing as information hiding,' then one might make the argument that 'everything that was encapsulated was also hidden.' This is obviously not true."
Conclusion:
"Abstraction, information hiding, and encapsulation are very different, but highly-related, concepts. One could argue that abstraction is a technique that help us identify which specific information should be visible, and which information should be hidden. Encapsulation is then the technique for packaging the information in such a way as to hide what should be hidden, and make visible what is intended to be visible."
Abstraction is hiding the implementation details by providing a layer over the basic functionality.
Information Hiding is hiding the data which is being affected by that implementation. Use of private and public comes under this. For example, hiding the variables of the classes.
Encapsulation is just putting all similar data and functions into a group e.g Class in programming; Packet in networking.
Through the use of Classes, we implement all three concepts - Abstraction, Information Hiding and Encapsulation
Please don't complicate simple concepts.
Encapsulation : Wrapping up of data and methods into a single unit is Encapsulation (e.g. Class)
Abstraction : It is an act of representing only the essential things without including background details. (e.g. Interface)
FOR EXAMPLES AND MORE INFO GOTO :
http://thecodekey.com/C_VB_Codes/Encapsulation.aspx
http://thecodekey.com/C_VB_Codes/Abstraction.aspx
Approved definitions here
P.S.: I also remember the definition from a book named C++ by Sumita Arora which we read in 11th class ;)
The meaning of abstraction given by the Oxford English Dictionary (OED) closest to the meaning intended here is 'The act of separating in thought'. A better definition might be 'Representing the essential features of something without including background or inessential detail.'
Information hiding is the principle that users of a software component (such as a class) need to know only the essential details of how to initialize and access the component, and do not need to know the details of the implementation.
Edit: I seems to me that abstraction is the process of deciding which parts of the implementation that should be hidden.
So its not abstraction VERSUS information hiding. It's information hiding VIA abstraction.
Abstraction
Abstraction is an act of representing essentail details without including the background details. A abstract class have only method signatures and implementing class can have its own implementation, in this way the complex details will be hidden from the user. Abstraction focuses on the outside view. In otherwords, Abstraction is sepration of interfaces from the actual implementation.
Encapsulation
Encapsulation explains binding the data members and methods into a single unit. Information hiding is the main purpose of encapsulation. Encapsulation is acheived by using access specifiers like private, public, protected. Class member variables are made private so that they cann't be accessible directly to outside world. Encapsulation focuses on the inner view. In otherwords, Encapsulation is a technique used to protect the information in an object from the other object.
Abstraction is hiding details of implementation as you put it.
You abstract something to a high enough point that you'll only have to do something very simple to perform an action.
Information hiding is hiding implementation details. Programming is hard. You can have a lot of things to deal with and handle. There can be variables you want/need to keep very close track of. Hiding information ensures that no one accidentally breaks something by using a variable or method you exposed publicly.
These 2 concepts are very closely tied together in object-oriented programming.
Abstraction - It is the process of identifying the essential characteristics of an object
without including the irrelevant and tedious details.
Encapsulation - It is the process of enclosing data and functions manipulating this data into a single unit.
Abstraction and Encapsulation are related but complementary concepts.
Abstraction is the process. Encapsulation is the mechanism by which Abstraction is implemented.
Abstraction focuses on the observable behavior of an object. Encapsulation focuses upon the implementation that give rise to this behavior.
Information Hiding - It is the process of hiding the implementation details of an object. It is a result of Encapsulation.
Abstraction : Abstraction is the concept/technique used to identify what should be the external view of an object. Making only the required interface available.
Information Hiding : It is complementary to Abstraction, as through information hiding Abstraction is achieved. Hiding everything else but the external view.
Encapsulation : Is binding of data and related functions into a unit. It facilitates Abstraction and information hiding. Allowing features like member access to be applied on the unit to achieve Abstraction and Information hiding
In very short
Encapsulation:– Information hiding
Abstraction :– Implementation hiding
Abstraction lets you focus on what the object does while Encapsulation means how an object works
Encapsulation: binding the data members and member functions together is called encapsulation. encapsulation is done through class.
abstraction: hiding the implementation details form usage or from view is called abstraction.
ex:
int x;
we don't know how int will internally work. but we know int will work. that is abstraction.
See Joel's post on the Law of Leaky Abstractions
JoelOnsoftware
Basically, abstracting gives you the freedom of thinking of higher level concepts. A non-programming analogy is that most of us do not know where our food comes from, or how it is produced, but the fact that we (usually) don't have to worry about it frees us up to do other things, like programming.
As for information hiding, I agree with jamting.
It's worth noting these terms have standardized, IEEE definitions, which can be searched at https://pascal.computer.org/.
abstraction
view of an object that focuses on the information relevant to a particular purpose and ignores the remainder of the information
process of formulating a view
process of suppressing irrelevant detail to establish a simplified model, or the result of that process
information hiding
software development technique in which each module's interfaces reveal as little as possible about the module's inner workings and other modules are prevented from using information about the module that is not in the module's interface specification
containment of a design or implementation decision in a single module so that the decision is hidden from other modules
encapsulation
software development technique that consists of isolating a system function or a set of data and operations on those data within a module and providing precise specifications for the module
concept that access to the names, meanings, and values of the responsibilities of a class is entirely separated from access to their realization
idea that a module has an outside that is distinct from its inside, that it has an external interface and an internal implementation
Abstraction allows you to treat a complex process as a simple process. For example, the standard "file" abstraction treats files as a contiguous array of bytes. The user/developer does not even have to think about issues of clusters and fragmentation. (Abstraction normally appears as classes or subroutines.)
Information hiding is about protecting your abstractions from malicious/incompetent users. By restricting control of some state (hard drive allocations, for example) to the original developer, huge amounts of error handling becomes redundant. If nobody else besides the file system driver can write to the hard drive, then the file system driver knows exactly what has been written to the hard drive and where. (The usual manifestation of this concept is private and protected keywords in OO languages.)
To abstract something we need to hide the detail or to hide the detail of something we need to abstract it.
But, both of them can be achieved by encapsulation.
So, information hiding is a goal, abstraction is a process, and encapsulation is a technique.
Abstraction simply means the technique in which only essential details of software is made visible to the user to help the user to use or operate with software, thus implementation details of that software are not shown(are made invisible).
Encapsulation is the technique that have package that hold one or more items and hence some of information (particularly program details) became visible and some not visible to the user, so encapsulation is achieved through information hiding.
In summary. Abstraction is for observable behavior (externally) and encapsulation is for invisibility (internally) but these two are really complementary.
Just adding on more details around InformationHiding, found This link is really good source with examples
InformationHiding is the idea that a design decision should be hidden from the rest of the system to prevent unintended coupling. InformationHiding is a design principle. InformationHiding should inform the way you encapsulate things, but of course it doesn't have to.
Encapsulation is a programming language feature.
Both Abstraction and Encapsulation are two of the four basic OOP concepts which allow you to model real-world things into objects so that you can implement them in your program and code. Many beginners get confused between Abstraction and Encapsulation because they both look very similar. If you ask someone what is Abstraction, he will tell that it's an OOP concept which focuses on relevant information by hiding unnecessary detail, and when you ask about Encapsulation, many will tell that it's another OOP concept which hides data from outside world. The definitions are not wrong as both Abstraction and Encapsulation does hide something, but the key difference is on intent.
Abstraction hides complexity by giving you a more abstract picture, a sort of 10,000 feet view, while Encapsulation hides internal working so that you can change it later. In other words, Abstraction hides details at the design level, while Encapsulation hides details at the implementation level.
After reading all the above answers one by one I cant stop myself from posting that
abstraction involves the facility to define objects that represent abstract "actors" that can perform work, report on and change their state, and "communicate" with other objects in the system.
Encapsulation is quite clear from above however ->
The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.
reference wiki
I too was very confused about the two concepts of Abstraction and Encapsulation. But when I saw the abstraction article on myjavatrainer.com, It became clear to me that Abstraction and Encapsulation are Apples and Oranges, you can't really compare them because both are required.
Encapsulation is how the object is created, and abstraction is how the object is viewed in the outside world.
Encapsulation: binding data and the methods that act on it. this allows the hiding of data from all other methods in other classes.
example: MyList class that can add an item, remove an item, and remove all items
the methods add, remove, and removeAll act on the list(a private array) that can not be accessed directly from the outside.
Abstraction: is hiding the non relevant behavior and data.
How the items are actually stored, added, or deleted is hidden (abstracted).
My data may be held in simple array, ArrayList, LinkedList, and so on.
Also, how the methods are implemented is hidden from the outside.
Encapsulation- enforcing access to the internal data in a controlled manner or preventing members from being accessed directly.
Abstraction- Hiding the implementation details of certain methods is known as abstraction
Let's understand with the help of an example:-
class Rectangle
{
private int length;
private int breadth;// see the word private that means they cant be accesed from
outside world.
//now to make them accessed indirectly define getters and setters methods
void setLength(int length)
{
// we are adding this condition to prevent users to make any irrelevent changes
that is why we have made length private so that they should be set according to
certain restrictions
if(length!=0)
{
this.length=length
}
void getLength()
{
return length;
}
// same do for breadth
}
now for abstraction define a method that can only be accessed and user doesnt know
what is the body of the method and how it is working
Let's consider the above example, we can define a method area which calculates the area of the rectangle.
public int area()
{
return length*breadth;
}
Now, whenever a user uses the above method he will just get the area not the way how it is calculated. We can consider an example of println() method we just know that it is used for printing and we don't know how it prints the data.
I have written a blog in detail you can see the below link for more info
abstraction vs encapsulation
Related
I would like to know what is the difference between the Visitor pattern and using a static method to execute code in separation.
Let's take a look at an example where I might call the Visitor pattern:
new AnalyticsVisitor.accept(myClass);
and this when called in from myClass for example, would move the work into a visitor to execute. It would even garbage collect faster if it's memory intensive.
Now lets take a look at using a simple method to achieve more or less the same thing:
new AnalyticsManager.execute(myClass);
Have I achieved the same thing?
I have code separation.
I can apply this to several data structures
I can add info to legacy code without changing it.
So why use the Visitor pattern instead of just a class (unless for double dispatch)?
This question is still a little confused. I suspect you haven't understood the goal of the Visitor pattern.
As discussed here the visitor pattern is useful when you have complex data structure (such as a parse tree) that is relatively stable (in terms of development), but you want to be able to keep adding new operations on all of its elements. This is clumsy with standard OO techniques.
The technology the visitor pattern is based on is double-dispatch, so when you say "Why use the Visitor pattern unless for double-dispatch?" you are effectively saying "Why use the visitor pattern?"
Your example code only includes the client, so it isn't clear what your new technique actually offers.
The supplied code appears to be backwards for a real visitor pattern. It should be:
my_datastructure.accept(analytics_visitor);
where analytics_visitor inherits from MyDataStructureVisitor, and supplies individual methods for each of the element types that the data structure can hold.
As for the achievements:
"Code separation" is a vague term. The visitor pattern allows the data structure to be defined without all the the operations (putative methods) to be defined. Instead, they can be defined separately - with a cost of poorer encapsulation.)
It isn't clear what it means to apply a visitor pattern to several data structures. Each visitor class is associated with one data structure.
The goal isn't to add 'info' to legacy code. It is to add operations to legacy code.
I am reading The Pragmatic Programmer: From Journeyman to Master by Andrew Hunt, David Thomas. When I was reading about a term called orthogonality I was thinking that I am getting it right. I was understanding it very well. However, at the end of the chapter a few questions were asked to measure the level of understanding of the subject. While I was trying to answer those questions to myself I realized that I haven't understood it perfectly. So to clarify my understandings I am asking those questions here.
C++ supports multiple inheritance, and Java allows a class to
implement multiple interfaces. What impact does using these facilities
have on orthogonality? Is there a difference in impact between using multiple
inheritance and multiple interfaces?
There are actually three questions bundled up here: (1) What is the impact of supporting multiple inheritance on orthogonality? (2) What is the impact of implementing multiple interfaces on orthogonality? (3) What is the difference between the two sorts of impact?
Firstly, let us get to grips with orthogonality. In The Art of Unix Programming, Eric Raymond explains that "In a purely orthogonal design, operations do not have side effects; each action (whether it's an API call, a macro invocation, or a language operation) changes just one thing without affecting others. There is one and only one way to change each property of whatever system you are controlling."
So, now look at question (1). C++ supports multiple inheritance, so a class in C++ could inherit from two classes that have the same operation but with two different effects. This has the potential to be non-orthogonal, but C++ requires you to state explicitly which parent class has the feature to be invoked. This will limit the operation to only one effect, so orthogonality is maintained. See Multiple inheritance.
And question (2). Java does not allow multiple inheritance. A class can only derive from one base class. Interfaces are used to encode similarities which the classes of various types share, but do not necessarily constitute a class relationship. Java classes can implement multiple interfaces but there is only one class doing the implementation, so there should only be one effect when a method is invoked. Even if a class implements two interfaces which both have a method with the same name and signature, it will implement both methods simultaneously, so there should only be one effect. See Java interface.
And finally question (3). The difference is that C++ and Java maintain orthogonality by different mechanisms: C++ by demanding the the parent is explicitly specified, so there will be no ambiguity in the effect; and Java by implementing similar methods simultaneously so there is only one effect.
Irrespective of any number of interfaces/ classes you extend there will be only one implementation inside that class. Lets say your class is X.
Now orthogonality says - one change should affect only one module.
If you change your implementation of one interface in class X - will it affect other modules/classes using your class X ? Answer is no - because the other modules/classes are coding by interface not implementation.
Hence orthogonality is maintained.
Me and my colleague are developing an ms access based application. We are designing and coding different pages/forms in order to divide work. We plan to merge our work later. How can we do that without any problems like spoiling the design and macros? We are using Ms access 2007 for front end and sqlserver 2005 as the datasource.
I found an idea somewhere on bytes.com. I can import forms, reports, queries,data and tables that I want.I'm going to try this. However, it's just an idea.So, need to study this approach by trial and error techniques.
The most important requirement is to complete the overall design before you start coding. For example:
All the forms must have the same style. Help and error information must be provided in the same way on each form. If a user can divide the forms into two sets, you have failed.
The database design must be finished with a complete, written description of each table, its relationships and its attributes.
The purpose and parameters for each major macro must be defined. If macro A1 exists only to service macro A then A1 is not a major macro and only A's author need know of its details until coding is complete.
Agreed a documentation style and detail level. If the application needs enhancement in six or twelve months' time, you should be able to work on the others macros and forms as easily as on your own.
If one of you thinks a change to the design is required after coding has started, this change must be documented, agreed with the other and the change specification added to the master specification.
Many years ago I lectured on (Electronic Data interchange (EDI). With EDI, the specification is divided into two with one set of organisations providing applications for message senders and another set providing applications for message receivers. I often used an example in my lectures to help my audience understand the importance of a complete, unambiguous specification.
I want two shapes, an E and a reverse-E, which I can fit together to create a 10 cm square. I do not care what they are made of providing they fit together perfectly.
If I give this task to a single organisation, this specification will be enough. One organisation might use cardboard, another metal, but I do not care. But suppose I ask one organisation to create the E and another the reverse-E. How detailed does my specification have to be if I am to get my 10 cm square? I would suggest: material, thickness and dimensions of the E. My audience would compete to suggest more and more obscure characteristics that had to match: density, colour, pattern, texture, etc, etc.
I was not always convinced my audience listened to the rest of my lecture because they were searching for a characteristic that would cap all the others. No matter, I had got across my major point which was why EDI specifications were no mind-blowingly detailed.
Your situation will not be so difficult since you and your colleague are probably in the same room and can talk whenever you want. But I hope this example helps you understand how easy is it for the interface between your two parts to be less than seamless if you do not agree the complete design at the beginning. It's the little assumptions - I though you knew I was doing it that way - that will kill your application.
New section
OK, probably most of my earlier advice was inappropriate in your situation.
So you are trying to modify code you did not write in a language you do not know. Good luck; you will need it.
I think scope is going to be your biggest problem. Most modern languages have namespaces allowing you to give a variable or a routine as much or as little scope as you require. VBA only has three levels.
A variable declared within a function or subroutine is automatically private to that function or subroutine.
A variable declared as Private within a module is invisible to functions and subroutines in other modules but is visible to any function or subroutine within the module.
A variable declared as Public within a module is visible to any function or subroutine within the project.
Anything declared within a form is private to that form. If a form wishes to pass a value to an outside function or subroutine, it can do so by writing to a public variable or by passing it in a parameter to a public function or subroutine.
Avoiding Naming Conflicts within VBA Help gives useful advice.
Form and module names will have to be unique across the merged project. You will not be able to avoid have constants, variables, functions and sub-routines which are visible to the other's functions and sub-routines. Avoiding Naming Conflicts offers one approach. An approach I have used successfully is to divide the application into sub-applications and, if necessary, sub-sub-applications and to assign a prefix to each. If every public constant, variable, function and sub-routine name has the appropriate prefix you can simulate namespace type control.
Can anyone tell me with examples abstraction and encapsulation and difference between them?
They're certainly related, but subtly different.
Abstraction is the treating of concrete classes (types of objects) as abstractions. By that, I mean you don't have classes representing square, circle, rectangle and so on. All these can be abstracted to a common ancestor, shape. The abstraction is useful because there are certain operations that you can perform on any shape, such as drawing, setting the origin, setting the size and so on.
Encapsulation, on the other hand, is information hiding. It's the act of exposing only enough information to enable you to do what needs to be done.
A classic example there is a telephone book. You don't expose the fact that you're using a hash table or a couple of arrays or whatever bizarre structure you've chosen to represent it. Instead you provide only the operations that you expect to carry out on an object.
Encapsulation lets you change the internals of a class without having to worry about effects on the client. So maybe an array is fine when your phone book has twenty entries in it but, when you get so popular that people are clamouring to be added, you may want to switch to using hash tables or a database.
With encapsulation, this is a far more painless process since, as long as you maintain the public face of your class, you can change what you want. If you had "published" your internals, people may have come to depend on that, to the point where that dependency would break their code when you changed it. A good rule is to only "publish" what you expect to never change.
Encapsulation eases the task of abstraction since the internal details of an class are hidden from view.
Encapsulation:
Encapsulation is essentially the hiding of implementation details, separating data and behavior, and providing simple interfaces to complex black box entities.
Example: you press the toast lever down on your toaster, it activates the heating coils & timer, and your toast pops up ready to eat in a minute. The details of making toast are encapsulated into a simple interface of pushing the lever down. In 20 years, you might buy a nuclear toaster, but the same encapsulation of functionality will allow you to use it in the manner you're accustomed to now.
Abstraction:
Definition 1
In the general sense, the interface provided by an encapsulation is essentially an abstraction for its more complex innards. With this definition, the distinction is blurred.
Example: the same toaster from above can be said to be abstracting the complex action of toasting bread into a simple operation of pushing a lever.
Definition 2
Another more distinct meaning is the use of a hierarchy of types or other generality to allow entities to be used interchangeably in their more generic forms. Encapsulation often enables this type of abstraction.
Example: your toaster can toast slices of wheat bread, rye bread, raising bread, or even bagels. The only requirement is that they be sliced and limited to some common set of dimensions. Here we might say that your toaster can toast anything "Toastable". This is an abstraction that encompasses all of these items.
Grady Booch says...
(from http://en.wikipedia.org/wiki/Information_hiding)
In his influential book on object-oriented design, Grady Booch defined encapsulation as "the process of compartmentalizing the elements of an abstraction that constitute its structure and behavior; encapsulation serves to separate the contractual interface of an abstraction and its implementation."[2] This formulation is cited by a number of books as an authoritative definition of encapsulation.
Does Encapsulation is information Hiding or it leads to information hiding??
As we say that Encapsulation binds data and functions in a single entity thus it provides us control over data flow and we can access the data of an entity only through some well defined functions. So when we say that Encapsulation leads to abstraction or information hiding then it means that it gives us an idea which data to hide and which data to show to users... coz the data that users cant access can be hidden from them thus encapsulation gives us a technique to find out what data to be hidden and what should be visible... Is this concept correct??
And what is the difference between information hiding and abstraction??
Possible duplicate of the this
public class Guest {
private String name;
public String getName() {
return name;
}
public void setName(String name) {
this.name = name;
}
}
See the above code, we have encapsulated the String name, we provide the access to it through public methods.
Say we have created object of Guest called guest. Then the following will be illegal.
System.out.println("Guests name : "guest.name);
Access through public methods is what can only be done.
guest.getName();
Benefits of Encapsulation:
The fields of a class can be made
read-only or write-only.
A class can have total control over
what is stored in its fields.
The users of a class do not know how
the class stores its data. A class
can change the data type of a field,
and users of the class do not need
to change any of their code.
Encapsulation means hiding the implementation
Abstraction means providing blueprint about the implementation
Data Hiding means controlling access to DataMember or attributes
Information is a more general term, hence, i believe, to say Encapsulation is Information hiding, will not be appropriate.
I would say Encapsulation is Data Hiding.
Encapsulation means ...
Combining an Object's State & behavior (that operates on that State), in one single unit.
This closely mimics a real world Object.
Hiding & Securing Object's State from accidental external alterations by providing a well-defined, controlled access (through behaviors).
In Java, the definition can be detailed out as ...
In Java, Classes and Enums are single units for implementing encapsulation. State is defined using variables (primitives, references to objects), and behavior using methods.
Data Hiding is achieved using private access specifier on variables (so that no one can access them from outside).
Controlled Access is achieved by providing Getters / Setters and/or business logic methods. Both Setters and other State affecting methods should have boundary condition checks for keeping the State logically correct.
Encapsulation talks about hiding data into something and give it a name ( private data members in a class - Car) and binding behavior methods with it which will mutate or provide access to those data variables.
Abstraction provides perspective of the client in abstract terms. As a concept or idea. Car is concrete entity where as Drivable, Trackable(which has position and can be tracked down) can be abstraction for Car for different clients.
You can check some real life examples of Abstraction and Encapsulation here.
Encapsulation is a technique used for hiding properties & behavior of an object.
Abstraction refers to representing essential features.
Encapsulation - Work complete and door permanently closed. Get work benefits through method name.
Abstraction - Work started and door temperately closed. Open and change work using overriding Key.
Both these OOP principles involve information hiding but are different.
Encapsulation involves restricting the direct access to the variables of the class by making them private and giving public getters and setters to access them.
Purpose: This is done so that the members of the class cannot be accidentally manipulated (and thus corrupted) from outside.
Abstraction involves exposing only the relevant details to the caller while hiding other details (details of implementation). The client does not need to bother about implementation which may change later. Example: The caller will call the add method of List, the implementation of which may be ArrayList today but may change to LinkedList tomorrow.
Purpose: This provides flexibility that tomorrow the implementation can be changed. Also, it simplifies the design.