Abstraction -- The ability to ignore the inner details and concentrate on the functionality.
Abstraction enables programmers to use a class without knowing how it is implemented: All that is required is for the Contract (ie: Interface, properties, methods and their parameters) to be defined, and all interaction between the "new" program and the class must be according to this abstract contract (defined interface).
Abstraction also enables Polymorphism to easily be implemented in OOP: By defining the interface, different programmers ( prgmr_a, prgmr_b ) can implement it by subclassing it (subclass_a, subclass_b). The "new" program can then make use of either subclass_a or subclass_b without caring how it was implemented.
CLASS pet (SUBCLASS OF animal)
CLASS petdog (SUBCLASS OF pet)
CLASS petcat (SUBCLASS OF pet)
CLASS petbird (SUBCLASS OF pet)
Now, given the above class hierarchy, a vet's office program could have a list of "pet" objects, and wouldn't care if they were "petdog" or "petcat", it would be able to get the "name" of the pet, and the "owner"'s name, and the "owners_address".
Each subclass can override the "eat" method to be more appropriate to itself; the definition of the "eat" method in the "animal" class would be "abstract", not implemented there: Only a template that would be implemented in a subclass, but garanteed to exist in the subclass. In fact, the entire "animal" class could be an abstract class, if it defines no functionality inside it. In this way an "abstract class" can be comparable to a COM "interface" that you can "implement" in VFP7.
Implementing Interfaces is ActiveX/COM's way of accomplishing what AbstractClasses does for OOP. (Interfaces are more flexible in a way because they aren't bound to an object hierarchy: a single object can implement several different interfaces, while any class can only inherit from one parent class (understanding that includes the parent's parent, grandparent, etc.) )
See also: The Layers Design Pattern
( Topic last updated: 2001.07.25 12:08:08 PM )