-3

I was hoping that someone could explain to me in the simplest way possible and with an example, what abstraction is with regards to Oop. I've read articles online and I just don't get it. I'm hoping a simple coding example would help it sink in. I understand it's the concept of hiding complexity from the user and I understand real life examples like a coffee machine. A user doesn't need to know the complexity of how it makes the coffee, just that they need to insert a coffee pods and press a button.

I'd really appreciate any help,

Thanks :)

CodeLearner
  • 117
  • 1

3 Answers3

1

The meaning of the word in programming is no different from its use outside of the field. It basically means taking away everything that ties something to a concrete incarnation. What is left are properties that you can still talk about and apply logic to.

Example: cat. That is a real animal. You can picture it. You can tell it is different from any other animal. Real world incarnations of cats exist.

So cat is not abstract. Animal though is abstract. There is no such thing as an animal, it is either a cat or a dog or a frog, but there are no animals. Still the concept animal is something we use and talk about. It is a classification of things.

In OO you use abstractions as a base for modeling. You put generic properties in the abstract class(ification) and share that set of properties among more concrete things.

Martin Maat
  • 18,218
  • 3
  • 30
  • 57
  • Be careful with using biology for analogies. "Cat" is still an abstraction. There are animals, eg fossas, that look like cats but aren't. Biology is messy and organisms do not neatly fit into ordered classifications, especially when compared to highly ordered systems like types in programming languages. – David Arno Jan 11 '19 at 08:26
0

Abstraction is a method of protecting the reader of computer code from information overload.

It goes together with OOP very well, since the point of object orientation is to create software entities that correspond as closely as possible to real-word things that the information worker already knows. As long as the object behaves in the expected way (according to someone's pre-existing world knowledge), its internal workings can be ignored, leaving more intellectual capacity for the rest of the system.

For instance, a system that models travel bookings must know a great deal about means: airlines, transit times, visa requirements etc. etc. However, a user (or another software component) that wants to use this system should be able to do so without knowing all these details, ideally without knowing anything more than the goal: "I want to get from XX to YY on DD.MM.YYYY". If a system achieves this, then its usefulness is much higher than that of a system that intermixes goals and means.

Abstraction is simply a name for the phenomenon that most of the components, methods etc. used to build an object can remain invisible to the user of that object, because all they do is fulfill expectations that the user already had.

Kilian Foth
  • 107,706
  • 45
  • 295
  • 310
0

A user doesn't need to know the complexity of how it makes the coffee, just that they need to insert a coffee pods and press a button.

You've already hit the nail on the head.  Abstraction is about removing irrelevant details of implementation in order to focus on the relevant details.  It goes the the distinction you're describing.

In the real world, such irrelevant detail quickly goes to molecules, studies of chemistry, physics, etc... when all we're interested in is the cup of coffee.

In programming, it is a bit different, since we're dealing with information manipulation rather than molecules, so it goes to how we distance the details of the algorithms and state needed to accomplish the result — which may be a cup of coffee object being created, or may be an espresso machine controller that coordinates the making of coffee in the real world.

Fundamentally, in programming abstraction goes to the separation of the interface that the client uses/sees and the underlying implementation that is provided to make these things happen — which is a bit different from the real world, since we are manipulating state instead of molecules.  By separating the interface from the implementation we both focus on the relevant (as the author sees fit) and de-focus on the implementation.

Generalization is a refactoring that allows one interface to work across several different scenarios (as in finding what common ground there is among different types objects).  It is closely related to abstraction as generalization also focuses attention on relevant while holding off on the irrelevant, though it is done with a particular focus on the common ground vs. the specializations.

Encapsulation is enclosing internal details of something with the objective of limiting/controlling/hiding how the object can be interacted with from the outside world.  So, encapsulation also hides implementation details while focusing on the relevant interface for the consumer, but it goes somewhat more to the intent of preventing incorrect update/modification/usage of an encapsulated entity rather than abstractions focus on the interface.

All of these arguably have overlap, and go together in OOP.

Abstraction can be done via a single function which is an interface of sorts (often called a signature in OOP), or a group related of functions (often called an interface in OOP, also goes to the class construct), or a forest of interfaces/classes (often done using a namespace in OOP).

In some languages these are formal constructs, though these approaches can also be done in languages that don't offer (one or more of) these as formal constructs.

Generalization goes to the class and interface hierarchy, in that typically we have a base class or an interface representing the common ground among several concepts, and then specializations (concrete implementations of interfaces, or subclasses of base classes) that offer the differentiating for these concepts.  So, abstraction on several levels.

While encapsulation's objective is to foster appropriate usage and deny inappropriate usage by information and capability hiding using private vs. public, for example.

Erik Eidt
  • 33,282
  • 5
  • 57
  • 91