A good off-the-cuff definition of abstraction is "selective ignorance". It basically means selecting specific parts of a particular thing to pay attention to. For instance, let's say that you own an ice cream shop and you hire a new employee to scoop ice cream and he asks, "Can I put mint chocolate chip into a cup if a customer wants it? What about putting vanilla into a sugar cone? And what about waffle cones?"
You could go through each flavor and each container with him, and draw a map of each possible combination of flavors of ice cream to container type. Or, you could selectively pick things to ignore about the flavors of ice cream (specifically, the flavor itself, just paying attention to the fact that it's ice cream) and the different kinds of containers (specifically, whether it's made out of edible waffle-pressed material, styrofoam, etc).
It's much easier to introduce an abstraction and simply say, "You can put any ice cream into any of the containers." That's abstraction.
You have to be careful about where you apply abstraction. For instance, let's say that you have a policy at your creamery that you don't allow customers to order chocolate toppings on any ice cream flavor that contains chocolate already (like mint chocolate chip or cookie dough chocolate chip--it's too much chocolate and customers invariably get angry and try to return it b/c it puts them into choco-overload). Yes this is an arbitrary example (but let's selectively ignore the fact that it's contrived...as if choco-overload is possible, right?). In this case, when your new employee asks about toppings, you can't simply refer to them as "toppings". You have to refer to them as "chocolate toppings" and "non-chocolate toppings". There's no such thing as a "non-chocolate topping". There *is* such a thing as raspberry sauce, peanuts, etc. But if I ask you to think of a "non-chocolate topping" without picturing a *specific* non-chocolate topping, you can't do it. So we can arbitrarily create abstractions that fit the particular features of the problem space we're trying to address...I just made up the distinction between chocolate toppings and non-chocolate toppings because it happens to allow us to ignore just the right things about the toppings we're dealing with, while at the same time paying attention to just the right things we're concerned about.
It's like trying to think of a color without thinking of a *particular* color, or a dog without picturing a dog with specific features that might not necessarily be present on all dogs. Abstractions don't really exist, is what I'm getting it. They're useful constructions for allowing us to divide up the world into features we care about for a particular purpose and ignore the ones we don't care about for the purpose at hand. That doesn't mean those ignored features don't actually exist, it just means that they make no difference to the thing we're trying to accomplish at the moment. Just like the distinction between peanuts and almonds (when it comes to topping a scoop of ice cream) is unimportant. The distinction between chocolate sauce and almonds, though, is very important because it means we have to evaluate whether the ice cream flavor can pair with that topping. Also note that these abstractions tend to happen in groups--it's useful also to create another abstraction to help us with this problem: chocolate-containing ice creams vs ice cream flavors that do not contain chocolate.
sev [ May 31, 2004: Message edited by: sever oon ]
There's a great quote about abstractions not being vague, but being at a high enough level that they can be precise. I'll try to find the exact words, but you get the idea (hey, an abstraction!)
Sever Oon gave some great examples. To more specific OO examples, we often say stuff like "abstract that behavior out of this class", meaning move some of the details we're dealing with here to some place I can talk about their effect in abstract terms and forget the details. For example, Set.add(thing) is a nice abstraction for a whole bunch of code that might see if thing is already there or keep a lot of things in sorted order. It would be a nightmare if we all had to think of all those details every time we added something to a Set.
A really nice feature of not knowing the details of how something is done is that somebody can change those details and not break our code. Maybe in the next release of the JVM Sun finds a way to make add() twice as fast. We don't know any of the details, we don't make use of them in any way, so Sun is free to change the details without even telling us.
I was working with a friend on a design, encouraging him to pull details out of a big class, add more abstractions and practice information hiding. He pointed out that it's hard to see the value when you're the only programmer. You can't exactly hide information from yourself. True enough, it's exactly the same code just moved around. But the value is still huge when you want to change a concrete implementation and not worry about breaking a lot of other code that depends on the abstract definition of what we're doing.
I'm always delighted when somebody asks questions like this. If all that sounds interesting, scroll down to the OO and UML forum and see what kind of conversations are going on there. [ May 31, 2004: Message edited by: Stan James ]
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
Joined: Jun 16, 2003
thanks a lot for your reply. and Lasse link's were really helpful. and Sever's Icecream example made me hungry too.
Joined: Jan 23, 2002
Originally posted by Anurag Mishra: and Sever's Icecream example made me hungry too.