Abstraction in OOP: multiple, yet rather distinct, contexts? [closed]

Question

I've been doing some research on OOP concepts and am having a bit of an issue in trying to understand what exactly Abstraction is. I've gone over numerous Stack Overflow posts on the topic but haven't really been able to pinpoint a satisfying answer.

I've seen a lot of discussions on the differences between Abstraction and Encapsulation, and naturally started started thinking about Abstraction in terms of hiding how a particular class works and providing abstraction through the class API. Here are some posts that steered me in this direction:

• Best voted answer refers to functions being Abstract. The very next answer starts talking about abstract classes...
• Best voted answer seems to refer to exposing through the class API while the next two goes off in an Inheritance setting. Third answer even suggests Composition and Aggregation is considered an Abstraction

However, as I read through more posts, I noticed answers portraying Abstraction in an Inheritance context, specifically using interfaces and abstract classes to provide an Abstraction of a certain entity (class). I assumed Abstraction given in this manner would allow developers to extend new objects appropriately according to the "guidelines" outlined by this Abstraction. Here are some posts that lead me in this direction:

• First couple of answers talk about Abstraction in an abstract class/interface setting, while some down the line start talking about exposing classes through APIs
• Top two voted answers refer to abstract classes/interfaces

I'm not sure if I'm just completely missing the point here, but it's getting pretty confusing because every answer seems to add a slight variation to the mix. I definitely see why both contexts are crucial in Object Oriented Programming, but I really wanted a clear-cut definition of what Abstraction is.

Which brings me to my point: does Abstraction work in multiple contexts? Does Abstraction portray both of these concepts?

1. Hiding away "unnecessary details" as done through interfaces and abstract classes

   • Providing an abstraction on a class to be created through interfaces and abstract classes. We can provide an interface of IPet which would act as an abstraction of a Dog class. Additionally, we could provide an Animal base class as an abstract class to provide a higher level abstraction. This could let us use Polymorphism and allow different classes that fall under our Animal abstraction to interact with one another.

2. Abstracting the implementation of a class by exposing it through the class API

   • given a Dog class, we just need to know that it has a feed() function as part of its API, and call that function to feed it without knowing how the feeding is actually done. This provides abstraction on the Dog class and lets us easily interact with the class

One of the links I've included above contains the following quote by Matthew Watson that says:

"The problem is that there are no precise definitions for these concepts, and the words themselves have multiple meanings even within the context of object orientation."

Is it just that Abstraction is so abstract, even the definition is abstract :P? Thanks for any guidance in advance!

Edit: I'm rather new to SO and am not really aware of what the "primarily opinion based" flag entails. I don't see how this question is any less valid than the slew of questions regarding Abstraction on SO. I think it would be considered less opinion-based as I'm actually pinpointing two different contexts in which I think Abstraction makes sense in. I've seen many questions that just ask what Abstraction is, which I'd think is an even broader question than what I have here.

Answer 1

To me, abstraction is one of the most beautiful concepts of oo, which is actually what makes the program language very close to human thinking: we, humans always want to classify. Think of a car: your car. And let's approach that car in the context of a banker asking about your assets in the context of a loan: you will say you have assets (highest level of abstraction): an expensive car, a family car, a house, a boat, etc. They all have a specific value. Then suppose the context of the conversation switches to the banker having a personal interest in that car, given he's a car freak him selves. Now the cars will be described in more detail, and you can see different abstraction levels being defined: sport car with brand names, and lots more characteristics.

During the design time, your interest is about the levels of abstraction: What you want to do with it, i.e. its context. So, we will have the levels of abstraction: Asset, Car (and Boat and House), SportCar, FamilyCar. And so on. The context should never have more details than it needs, and this is what you're concerned about during design phase.

During the implementation phase, you will implement these levels of abstraction by encapsulating the properties that belong at these levels. E.g. Asset has a value, where Car has colour and SportCar might have some specific characteristics that a FamilyCar doesn't have.

So, key difference is: design time vs implementation time.

This blog post described the difference in much detail: http://javarevisited.blogspot.be/2017/04/difference-between-abstraction-and-encapsulation-in-java-oop.html

Here's another post at stackoverflow: What's the difference between abstraction and encapsulation?

Hope this helps.