The Old Joel on Software Forum: Part 3 (of 5)

OOP Concept: Abstraction?

Is "Abstraction" considered an OOP concept or is it simply a word that summarizes Polymorphism, Encapsulation and Inheritance? In other words, abstraction is achieved through the use of Polymorphism, Encapsulation and Inheritance.

All around the world, statues crumble for me
Friday, January 9, 2004

no, and no. You can have abstraction without using object oriented concepts. I've used abstraction in Perl and classic VB by having generic DataAccess methods, etc. I think your confused on the concepts a little...

vince
Friday, January 9, 2004

I'm not confused. Never have been. Whilst abstraction is a generic concept, I am not referring to it in this context.

All around the world, statues crumble for me
Friday, January 9, 2004

" In other words, abstraction is achieved through the use of Polymorphism, Encapsulation and Inheritance."

Yes, that's the whole point. Abstracting away from the "main()" part of the program. So main() is simple, but the library programming becomes more sophisticated. That appears to be the trade-off.

Abstract the work away from the developer to the SW Engineer.

Brian R.
Friday, January 9, 2004

Hrm... I think people are missing my question.

In school we were taught the there were 4 main OOP concepts: Abstraction, Polymorphism, Encapsulation and Inheritance. We were told that Overloading was not considered an OOP concept but a language feature.

I'm not talking about anything except the core OOP concepts here. I realize abstractions are created everywhere in programming. The languages we use to program are themselves abstractions. This is not what I'm referring to.

I am referring to core OOP concepts. Is abstraction considered to be a core OOP concept or not? If I go into an interview and the interviewer asks me what are the core OOP concepts? Would I be correct in saying abstraction is one of them? To me abstraction simply describes the other 3 concepts or more generally, like everyone else is saying, describes programming in general.

If abstraction is a core concept how would you define it in that context?

All around the world, statues crumble for me
Friday, January 9, 2004

"If I go into an interview and the interviewer asks me what are the core OOP concepts? Would I be correct in saying abstraction is one of them? "

Yes, an interface class is a good example of an abstraction. Also, your teacher left out composition. So there should be those five, in total, being the most basic concepts.

Another example of abstraction are delegates.

Brian R.
Friday, January 9, 2004

I don't see how abstraction would be considered a core part of OOP.

..but then again, I don't see how anyone can get hung up on definitions, or what makes OOP OOP.

Mark Hoffman
Friday, January 9, 2004

She did mention Object Composition but did not mention that it was a core concept.

I'm not hung up on it, I'm trying to understand it.

All around the world, statues crumble for me
Friday, January 9, 2004

I'll take a stab at this ...

I think by abstraction you are referring to 'design by contract'. Interfaces and abstract classes are typically responsible for enforcing decendant classes to implement certain behaviours.

I would certainly suggest that this is one of the major tenats of an OO language.

Canuck
Friday, January 9, 2004

An interface is not about abstraction it's about Polymorphism (one of the core concepts).

Composition is also not a _core_ OOP concept.

As for Abstraction, that's a really tough one. The more I think about it, the less I'm sure about. If someone can find a solid "Abstraction" example which is not in anyway object-related then I would say it's not a core OOP concept.

Almost Anonymous
Friday, January 9, 2004

No wait...

I suppose Abstraction as the separation of Interface from Implemenation is a core OOP concept.

Almost Anonymous
Friday, January 9, 2004

One successful model of objects says that classes are implementations of abstract data types. If you accept this view, then obviously abstraction is fundamental. There are other models of objects, though, where this is more debatable.

pgp
Friday, January 9, 2004

"I suppose Abstraction as the separation of Interface from Implemenation is a core OOP concept."

I personally consider interface-based programming to be orthogonal from object-oriented programming. You can do one without the other, and vice versa.

It just so happens that many object oriented languages have explicit constructs for interface based programming, but I think that's only because they are extremely complimentary. To this day, there is still no explicit support for interfaces in C++, but many consider it to be an OO language.

Brad Wilson (dotnetguy.techieswithcats.com)
Saturday, January 10, 2004

"To this day, there is still no explicit support for interfaces in C++, but many consider it to be an OO language."

Unfortunately the terms are extremely overloaded when dealing with OOP concepts. I mean "interfaces" is a general term in of itself but most of the time it's used to describe Java interfaces.

A Java-like interfaces are the same as abstract classes in C++.

As for interfaces (vs. Implementation) C++ doesn't do such a good job. In theory, the header file should be the Interface and the .cpp file be the implementation but that separation isn't clean in C++. Many implementation details are required to be in the header file.

Almost Anonymous
Saturday, January 10, 2004

Bruce Eckel gives good overview of the relationship between abstraction and OOP in chapter 1 of "Thinking in Java" (free download at http://www.mindview.net/Books/TIJ/ ).

No offense to anyone, but his explanation is a lot better than anything I've read in this thread so far.

Nick
Saturday, January 10, 2004

I found an on-line version, so you don't need to download it: http://jamesthornton.com/eckel/TIJ-3rd-edition4.0/TIJ303.htm

Scroll down one page to "The progress of abstraction"

Nick
Saturday, January 10, 2004

Abstraction has nothing to do with OOP in particular, albeit it can be implemented using OOP concepts. For example, the excellent book "Structure and Interpretation of Computer Programs" (also a course in many universities):

http://mitpress.mit.edu/sicp/

teaches about many abstractions that do not involve much OO. There's plenty of functional programming abstractions there.

Shlomi Fish
Saturday, January 10, 2004

If an interviewer asks you "What are the main concepts of OO?" then there are two possibilities.

1. The interviewer is a bit clueless, and is looking to see whether you give the same list that s/he learned at university (or reading "Visual Object Oriented Programming for Dummies in 21 Days with .NET for Java").

2. The interviewer is hoping that you won't just give a list of buzzwords, but will demonstrate that you actually have some mental structure underlying your use of the words by talking about how the various aspects of OO fit together, which things seem *to you* to be key and why, and so on.

In situation #1, probably the best you can do is to say "Inheritance, encapsulation and polymorphism". If you have some clue what the words mean too, congratulations; you probably know as much as your interviewer :-).

In situation #2, what the interviewer is looking for is real understanding, and that only comes from experience. The chances of any answer you get here helping much are small; the interviewer will expect you to talk about *why* you do or don't consider abstraction (or encapsulation, or whatever else) to be fundamental to OO, what difference removing it would make, how it relates to other aspects of OO programming.
In this situation, getting the "right" answer doesn't come into it, because a smart interviewer knows that there *is* no single right answer.

It might be helpful to look at some contrasting views on what OO is all about. For instance, you could read http://www.nhplace.com/kent/PS/Name.html (from a Common Lisp perspective; rejects, rightly in my opinion, the idea that encapsulation is a necessary part of OO) or Meyer's "Object-oriented software construction" (pretty much says that to be doing *real* OO you need to be programming in a language isomorphic to Eiffel). There are plenty of opinions in between.

Gareth McCaughan
Saturday, January 10, 2004

"abstraction simply describes the other 3 concepts"

I'd say this has it backwards. The goal of abstraction is to reduce a real world (or concrete object/problem) into a mathematical model (or abstract object) that only contains the attributes important to modelling/solving the problem with a computer program.

OOP defines tools (Inheritance, Encapsulation, Polymorphism, etc) that help you implement the abstract model; but you can produce an abstract model without them, and you can use them without producing an abstraction of anything concrete.

Tom Hathaway
Saturday, January 10, 2004

I think Tom's on the right track here.

Most OOP programmers don't do OOP because they're a bunch of language wonks who are just thrilled by the thought of pure virtual abstract classes. OOP isn't an intellectual exercise, it's there to get a job done. That job is to afford creation of large, complex programs written by large teams of disparate programmers.

Given that scenario, what tools do you need? You need tools that let you

* stick big chunks of related functionality into a small number of systems which can be reasoned about and used independenty of their implementation details, and developed independently of each other.

* easily model real-world concepts like "a manager is a kind of employee"

* re-use existing code

What I'm saying here is let's not put the cart before the horse. These things are tenets of OOP because these things are needed to solve the kinds of problems OOP was designed to solve.

Eric Lippert
Saturday, January 10, 2004

Doesn't abstraction work both ways?

It reduces a real world model of a problem into a "mathematical" representation.

It also reduces computer logic into routines that map to human readable forms of the real world problem.

They meet in the middle.

Saturday, January 10, 2004

Funny, I don't recall hearing any of the early OO proponents talking about *4* biggies, but rather the *3* big hallmarks of OO: Polymorphism, Encapsulation and Inheritance. If there is any broad concurrence in the OO community about what a language must provide to support an OO style, it's that minimally these *3* things must be present.

I'd describe Polymorphism and Encapsulation important tools of Abstraction available OO programmers. You'd have a hard time asserting Abstraction as a core defining characteristic of Object Oriented programming systems (as you could with the other three) only because you'd probably have a hard time finding *any* high-level programming system that doesn't support Abstraction well. (But the same might be somewhat true for Encapsulation too.)

veal
Sunday, January 11, 2004

I'll second that.

The way I heard it was that to be OO-compliant a language had to support Encapsulation, Inheritance and Polymorphism.

Abstraction isn't a defining feature of OO.

gwyn
Monday, January 12, 2004

Incidentally, I like this explanation:
http://www.paulgraham.com/reesoo.html

Tayssir John Gabbour
Monday, January 12, 2004