CSC/ECE 517 Fall 2009/wiki2 15 A&OM
Abstraction and the Object Model
Abstraction
Abstraction means hiding of details that are not relevant for the current viewpoint. For example, when we want search a path to reach an address in another city, we first consult a map of inter city highways. This map hides the city roads because they would clutter up the map too much. Once we have found a path to reach the destination city, we go down to the next lower level of abstraction, i.e. we consult the city road map to reach the desired locality. However this map hides small lanes and plot numbers. To locate the desired house number, we need the municipal survey map of that locality [1]. Abstraction can also be seen as a way to provide consistency to the user. For example, there are several car manufactures in the world, yet the interface offered to the drivers to operate any car is same. This consistency in the basic control mechanism enables the user to drive any car without any special training. A equivalent analogy in the software world will be GUI. Almost all applications developed these days have consistent GUI’s that is when you use any application you can be assured that there will be a tool bar and menu bar having options like print,edit open file etc. The following discussion on Object Models will show us how these principles of abstraction have been included in the Object Model.
Object Model
Three concepts are critical to understanding object models. They are:
- Data abstraction
- Encapsulation
- Inheritance
Encapsulation
The term encapsulation refers to the hiding of state details, but extending the concept of data type from earlier programming languages to associate behavior most strongly with the data, and standardizing the way that different data types interact, is the beginning of abstraction.
Data abstraction
Data abstraction is a methodology that enables us to isolate how a compound data structure is used from the details of how it is constructed from more primitive data types. The basic idea of data abstraction is to structure the programs that are to use compound data objects so that they operate on ``abstract data. That is, our programs should use data in such a way as to make no assumptions about the data that are not strictly necessary for performing the task at hand. At the same time, a ``concrete data representation is defined independent of the programs that use the data. The interface between these two parts of our system will be a set of procedures, called selectors and constructors, that implement the abstract data in terms of the concrete representation.
Inheritance
Inheritance in the object model is a means of defining one class in terms of another. This is common usage for most of us. For example, a conifer is a type of tree. There are certain characteristics that are true for all trees, yet there are specific characteristics for conifers.
In computer programming, abstraction can apply to control or to data: Control abstraction is the abstraction of actions while data abstraction is that of data structures.
- Control abstraction in involves the use of subprograms and related concepts control flows
- Data abstraction allows handling data bits in meaningful ways. For example, it is the basic motivation behind datatype.
One can regard the notion of object from object-oriented programming as an attempt to combine abstractions of data and code [2].
Abstraction in object oriented programming
Various object-oriented programming languages offer similar facilities for abstraction, all to support a general strategy of polymorphism in object-oriented programming, which includes the substitution of one type for another in the same or similar role. Although not as generally supported, a configuration or image or package may predetermine a great many of these bindings at compile-time, link-time, or loadtime. This would leave only a minimum of such bindings to change at run-time.
Common Lisp Object System or self, for example, feature less of a class-instance distinction and more use of delegation for polymorphism. Individual objects and functions are abstracted more flexibly to better fit with a shared functional heritage from Lisp.
C++ exemplifies another extreme: it relies heavily on templates and overloading and other static bindings at compile-time, which in turn has certain flexibility problems.
Although these examples offer alternate strategies for achieving the same abstraction, they do not fundamentally alter the need to support abstract nouns in code - all programming relies on an ability to abstract verbs as functions, nouns as data structures, and either as processes.
Consider for example a sample Java fragment to represent some common farm "animals" to a level of abstraction suitable to model simple aspects of their hunger and feeding. It defines an Animal class to represent both the state of the Animal and its functions:
public class Animal extends LivingThing {
private Location loc;
private double energyReserves;
boolean isHungry() {
return energyReserves < 2.5;
}
void eat(Food f) {
// Consume food
energyReserves += f.getCalories();
}
void moveTo(Location l) {
// Move to new location
loc = l;
}
}
With the above definition, one could create objects of type Animal and call their methods like this:
thePig = new Animal(); theCow = new Animal(); if (thePig.isHungry()) {
thePig.eat(tableScraps);
} if (theCow.isHungry()) {
theCow.eat(grass);
} theCow.moveTo(theBarn);
In the above example, the class Animal is an abstraction used in place of an actual animal, LivingThing is a further abstraction (in this case a generalisation) of Animal. If one requires a more differentiated hierarchy of animals — to differentiate, say, those who provide milk from those who provide nothing except meat at the end of their lives — that is an intermediary level of abstraction, probably DairyAnimal (cows, goats) who would eat foods suitable to giving good milk, and Animal (pigs, steers) who would eat foods to give the best meat-quality. Such an abstraction could remove the need for the application coder to specify the type of food, so s/he could concentrate instead on the feeding schedule. The two classes could be related using inheritance or stand alone, and the programmer could define varying degrees of polymorphism between the two types. These facilities tend to vary drastically between languages, but in general each can achieve anything that is possible with any of the others. A great many operation overloads, data type by data type, can have the same effect at compile-time as any degree of inheritance or other means to achieve polymorphism. The class notation is simply a coder's convenience.
Object-oriented design
Decisions regarding what to abstract and what to keep under the control of the coder become the major concern of object-oriented design and domain analysis — actually determining the relevant relationships in the real world is the concern of object-oriented analysis or legacy analysis. In general, to determine appropriate abstraction, one must make many small decisions about scope (domain analysis), determine what other systems one must cooperate with (legacy analysis), then perform a detailed object-oriented analysis which is expressed within project time and budget constraints as an object-oriented design. In our simple example, the domain is the barnyard, the live pigs and cows and their eating habits are the legacy constraints, the detailed analysis is that coders must have the flexibility to feed the animals what is available and thus there is no reason to code the type of food into the class itself, and the design is a single simple Animal class of which pigs and cows are instances with the same functions. A decision to differentiate DairyAnimal would change the detailed analysis but the domain and legacy analysis would be unchanged—thus it is entirely under the control of the programmer, and we refer to abstraction in object-oriented programming as distinct from abstraction in domain or legacy analysis. Abstract Class: An abstract class is a class whose instances can be created only in conjunction with an instance of one of its descendent subclasses
References
- http://highered.mcgraw-hill.com/sites/0070648255/information_center_view0/about_the_author.html
- http://www.service-architecture.com/database/articles/object_model_concepts.html
- http://mitpress.mit.edu/sicp/full-text/sicp/book/node27.html
- http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29