What is meant by "getting the right level of abstraction"?

I've read about how a hard job in programming is writing code "at the right level of abstraction". Although abstraction is generally hiding details behind a layer, is writing something at the right level of abstraction basically getting the methodss to implement decision correct? For example, if I am going to write a class to represent a car, I will provide properties for the wheels etc, but if I am asked to write a class for a car with no wheels, I will not provide the wheels and thus no method to "drive" the car. Is this what is meant by getting the abstractio开发者_如何学运维n right?

Thanks

Not Quite,

Providing the right level of abstraction is knowing how much of the information from the lower levels to pass up through your level.

Suppose you were writing a high level HTTP library. Perhaps you would provide a Get() method, a Head() method, a Post() method etcetera, but you wouldn't need to provide access to the underlying Sockets because you are abstracting that detail away from the user.

And below that Socket that you are using, there are layers of abstraction that you don't need to deal with. (You only access an abstraction one layer below you, beyond that it is the job of that layer to deal with the layer below it, and so forth).

For instance, you don't care about the sliding window flow control protocol because TCP is abstracting away those details.

--
If you are coding at too high of an abstraction layer for the purposes you are trying to achieve, you will run into multiple implementation details. When you are fighting with the library for control, it is an indication that perhaps you are working at too high a level.

Conversely, if you are coding at too low a level of abstraction you will get lost in the implementation details. Going back to my HTTP example, if you just want to run a Get request against the server and you are implementing a TCP handshake in your code, then perhaps you either want to try to use a library or abstract out your TCP code into a library and interface with it through that.

--
In one class that I took on the subject, the teacher had an interesting method of explaining abstractions. He had us think of them simply as a 'point of view' or 'perspective' on an object or a scenario.

The details that are important from one perspective aren't important at all from another perspective.

He put a book on a table and assigned roles to students such as "Reader", "Book Seller", "Author", "Librarian", or "Book Shipper" and asked us what details about the book we thought were important to us in that role. Based on the roll assigned to a person, their answers varied widely.

This represents an abstraction. Only needing those details that are important to you, and letting all other details be handled elsewhere (or simply fall to the wayside).

I don't think that's it.

To me, abstraction is synonymous with generalization. The more abstract something is, the more the author is trying to think about a problem in such a way that it's easier to extend and apply to new problems.

In general, greater abstraction requires more effort to develop and to understand. If you're a developer, and you're given a highly abstract framework to work with, you'll be forced to think in terms of the framework rather than using concepts that your common sense might suggest.

So, as in your example, a Car would be a very low level of abstraction. A RollingVehicle might be a higher one, and Transport might be the most abstract of all.

The right choice depends on how broadly you wish to apply your classes and how easily understood you'd like them to be.

I think one dangerous aspect of abstraction is its ability to erase or hide the reality or the design it represents. You should always maintain a reasonable distance between what you represent and the representation. By "reasonable" I mean easily understandable by an external developer how hasn't been coding on this specific project.

Joel Spolsky stated it quite right talking about the dangers of "architecture astronauts":

When great thinkers think about problems, they start to see patterns. They look at the problem of people sending each other word-processor files, and then they look at the problem of people sending each other spreadsheets, and they realize that there's a general pattern: sending files. That's one level of abstraction already. Then they go up one more level: people send files, but web browsers also "send" requests for web pages. And when you think about it, calling a method on an object is like sending a message to an object! It's the same thing again! Those are all sending operations, so our clever thinker invents a new, higher, broader abstraction called messaging, but now it's getting really vague and nobody really knows what they're talking about any more. Blah.