Abstraction is loosely defined as the opposite of attention (to detail). So, for example, the speedometer in a car is an abstraction of the device that actually tells you the speed. You do not need to know about the fact that there is a rotating magnet that is picked up by a sensor every time it passes a certain point and that generates a pulse stream the character of which a computer can turn into a meaningful number - you only care about the number, not the detail. In more of a computer context... The system APIs for either Windows or Linux provide a method of dealing with devices that are an abstraction of the actual operations required. In the linux API there are commands like open,close,read,write that a programmer can use to communicate with basically any device - whether it be a hard drive or a printer. The programmer then does not need to concern himself with the detailed requirements of every device. Inheritance on the other hand is useful for a number of reasons which I won't completely go into here, however, one is illustrated below: Specialization - You have a class Animal that has methods eat() and sleep() which is a good general contract. But then you can create a class Dog which 'is a' Animal and provides methods which are specialized to a Dog, like fetch() and bark() in addition to the inherited eat() and sleep() (which should also be overridden as a dog would eat in his own special way). Summing up (I hope that what I've written makes sense) - abstraction is used when you want to remove detail - when you're not concerned about the inner workings. This is usually one of the reasons we create classes. I don't care how an ArrayList stores or returns my information - only that it does. Inheritance is used to specialize or add-to the functionality of an already existing class and is characterized by the 'is a' relation. Scott
The concepts are really quite different. Abstraction is the process of doing things at the highest level possible. Think of it like a corporation. The president says "Get it done." The vice-president tells each of his underlings to do their part. Those managers then break the work up among their under-managers, and this process continues down the chain until it reaches the low-level workers, who actually do the "getting-it-done" part. All of this is invisible to the outside world, of course. The only thing visible is that the president said "get it done" and it got done. The same thing holds true for code. If you write a very specific function, it is only useful for a very specific purpose. If you write a function that basically tells someone else to "get it done," then it can be resused in many situations. The only difference, of course, will be in which other objects (underlings) it tells to do the work. Inheritance, on the other hand, is the process whereby object acquire traits from their super-classes. Syllogisms work here: All Vertebrata have Spines; a Platypus is a Vertebrata; therefore, a Platypus has a Spine What this means is that if you had a superclass called Vertebrata and you subclassed it with a class called Platypus, then the Platypus class will inherit all attributes of the superclass. Since one of the attributes of the Vertebrata class is a Spine object, then all of your Platypus-class objects will also have Spines. Note that, unless the Spine is declared as static, then each object will have its own Spine. (Which is the behavior that you would expect...) Of course, in the real worls, there would be many classes between Vertebrata and Platypus (Mammalia and Monotremata to name a couple...), but the effet is the same. A Platypus is a Vertebrata, therefore it has a Spine. [ February 05, 2004: Message edited by: Joel McNary ]
Piscis Babelis est parvus, flavus, et hiridicus, et est probabiliter insolitissima raritas in toto mundo.