Abstraction

48
Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary ABSTRACTION Muhammad Adil Raja Roaming Researchers cbnd April 7, 2015

Transcript of Abstraction

Page 1: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ABSTRACTION

Muhammad Adil Raja

Roaming Researchers

cbnd

April 7, 2015

Page 2: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

OUTLINE I

1 INTRODUCTION

2 LAYERS OF ABSTRACTION

3 OTHER FORMS OF ABSTRACTION

4 A SHORT HISTORY OF ABSTRACTION MECHANISMS

5 SUMMARY

6 REFERENCES

Page 3: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

INTRODUCTION I

An analogy from the world atlas.

Zooming in reveals finer details.

Zooming out reveals a different worldview at every step.

Consider an another analogy of automobiles.

A layman driver’s perspective is different than that of themechanic.

A mechanic’s perspective is different than that of an expertdesign engineer.

Page 4: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

INTRODUCTION II

DEFINITION

Abstraction is the purposeful suppression, or hiding, of somedetails of a process or artifact, in order to bring out more clearlyother aspects, details, or structure.

DEFINITION

Information hiding is the purposeful omission of details in thedevelopment of an abstract representation.

Page 5: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF ABSTRACTION I

In a typical program written in the object-oriented stylethere are many important levels of abstraction.The higher level abstractions are part of what makes anobject-oriented program object-oriented.At the highest level a program is viewed as a “community”of objects that must interact with each other in order toachieve their common goal.The notion of community has two different forms in OOP.A community of programmers.A community of objects they create.The ideas of abstraction and information hiding areapplicable to both levels.

Page 6: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF ABSTRACTION II

Each object in this community provides a service that isused by other members of the organization.At this highest level of abstraction the important features toemphasize are the lines of communication andcooperation, and the way in which the members mustinteract with each other.A higher level of abstration (than this) is not available in allOOP programs or languages.However, in languages such as java similar types ofobjects are grouped together to form singular units innamespaces and packages etc.The unit allows certain names to be exposed to the worldoutside the unit, while other features remain hidden insidethe unit.

Page 7: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF ABSTRACTION III

The next two levels of abstraction deal with the interactionsbetween two individual objects.Often we speak of objects as proving a service to otherobjects.We build on this intuition by describing communication asan interaction between a client and a server .A server means something that provides a service (and nota web server) in this context.

in ter face Stack {public void push ( Object va l ) ;public Object top ( ) throws EmptyStackException ;public void pop ( ) throws EmptyStackException ;}

Page 8: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF ABSTRACTION IV

FINDING THE RIGHT LEVEL OF ABSTRACTION

In early stages of software development a critical problem isnding the right level of abstraction. A common error is to dwellon the lowest levels, worrying about the implementation detailsof various key components, rather than striving to ensure thatthe high level organizational structure promotes a cleanseparation of concerns.The programmer or, in larger projects, the design team mustwalk a ne line in trying to identify the right level of abstraction atany one point of time. One does not want to ignore or throwaway too much detail about a problem, but also one must notkeep so much detail that important issues become obscured.

The next level of abstraction looks at the same boundarybut from the server side.

Page 9: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF ABSTRACTION V

This level considers a concrete implementation of theabstract behavior.For example, there are any number of data structures thatcan be used to satisfy the requirements of a Stack.Concerns at this level deal with the way in which theservices are being realized.

public class L inkedL i s t implements Stack . . . {public void pop ( ) throws EmptyStackException { . . . }. . .}

Finally, the last level of abstraction considers a single taskin isolation;that is, a single method.

Page 10: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF ABSTRACTION VI

Concerns at this level of abstraction deal with the precisesequence of operations used to perform just this oneactivity.

For example, we might investigate the technique used toperform the removal of the most recent element placed intoa stack.

Page 11: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF ABSTRACTION VII

public class L inkedL i s t implements Stack . . . {. . .public void pop ( ) throws EmptyStackException {i f ( isEmpty ( ) )throw new EmptyStackException ( ) ;removeFirs t ( ) ;/ / de le te f i r s t element o f l i s t}. . .}

Each level of abstraction is important at some point duringsoftware develop- ment.In fact, programmers are often called upon to quickly moveback and forth between di erent levels of abstraction.

Page 12: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

OTHER FORMS OF ABSTRACTION I

Abstraction is used to help understand a complex system.In a certain sense, abstraction is the imposition of structureon a system.The structure we impose may reflect some real aspects ofthe system a car really does have both an engine and atransmission or it may simply be a mental abstraction weemploy to aid in our understanding.This idea of abstraction can be further subdivided into avariety of different forms Figure 2.1.A common technique is to divide a layer into constituentparts.This is the approach we used when we described anautomobile as being composed of the engine, thetransmission, the body and the wheels.

Page 13: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

OTHER FORMS OF ABSTRACTION II

The next level of understanding is then achieved byexamining each of these parts in turn.This is nothing more than the application of the old maximdivide and conquer .Other times we use di erent types of abstraction.Another form is the idea of layers of specialization.An understanding of an automobile is based, in part, onknowledge that it is a wheeled vehicle , which is in turn ameans of transportation .There is other information we know about wheeledvehicles, and that knowledge is applicable to both anautomobile and a bicycle.

Page 14: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

OTHER FORMS OF ABSTRACTION III

There is other knowledge we have about various di erentmeans of transportation, and that information is alsoapplicable to pack horses as well as bicycles.

Object oriented languages make extensive use of this formof abstraction.

Yet another form of abstraction is to provide multiple viewsof the same artifact.

Each of the views can emphasize certain detail andsuppress others, and thus bring out di erent features of thesame object.

A laymans view of a car, for example, is very different fromthe view required by a mechanic.

Page 15: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

OTHER FORMS OF ABSTRACTION IV

IS-A AND HAS-A ABSTRACTION

The ideas of division into parts and division into specializationsrepresent the two most important forms of abstraction used inobject-oriented programming. These are commonly known asis-a and has-a abstraction.The idea of division into parts is has-a abstraction. Themeaning of this term is easy to understand; a car “has-a”engine, and it “has-a” transmission, and so on.The concept of specialization is referred to as “is-a” abstraction.Again, the term comes from the English sentences that can beused to illustrate the relationships.A bicycle “is-a” wheeled vehicle, which in turn “is-a” means oftransportation.Both is-a and has-a abstractions will reappear in later chaptersand be tied to specific programming language features.

Page 16: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

DIVISION INTO PARTS I

The ideas of division into parts and division intospecializations represent the two most important forms ofabstraction used in object-oriented programming.These are commonly known as is-a and has-a abstraction.The idea of division into parts is has-a abstraction. Themeaning of this term is easy to understand; a car has-a"engine, and it has-a" transmission, and so on.The concept of specialization is referred to as is-a"abstraction. Again, the term comes from the Englishsentences that can be used to illustrate the relationships.A bicycle “is-a” wheeled vehicle, which in turn “is-a” meansof transportation.

Page 17: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

DIVISION INTO PARTS II

Both is-a and has-a abstractions will reappear in laterchapters and be tied to specific programming languagefeatures.Another example might be organizing information aboutmotion in a human body.At one level we are simply concerned with mechanics, andwe consider the body as composed of bone for rigidity,muscles for movement, eyes and ears for sensing, thenervous system for transferring information and skin tobind it all together. At the next level of detail we might askhow the muscles work, and consider issues such as cellstructure and chemical actions.But chemical actions are governed by their molecularstructure.

Page 18: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

DIVISION INTO PARTS III

And to understand molecules we break them into theirindividual atoms.

Any explanation must be phrased at the right level ofabstraction; trying to explain how a person can walk, forexample, by understanding the atomic level details isalmost certainly di cult, if not impossible.

Page 19: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ENCAPSULATION AND INTERCHANGEABILITY I

A key step in the creation of large systems is the divisioninto components.Suppose instead of writing software, we are part of a teamworking to create a new automobile.By separating the automobile into the parts engine andtransmission , it is possible to assign people to work on thetwo aspects more or less independently of each other.We use the term encapsulation to mean that there is astrict division between the inner and the outer view;Those members of the team working on the engine needonly an abstract outside, as it were view of thetransmission, while those actually working on thetransmission need the more detailed inside view.

Page 20: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ENCAPSULATION AND INTERCHANGEABILITY II

An important bene t of encapsulation is that it permits us toconsider the possibility of interchangeability.

When we divide a system into parts, a desirable goal isthat the interaction between the parts is kept to a minimum.

For example, by encapsulating the behavior of the enginefrom that of a transmission we permit the ability toexchange one type of engine with another without incurringan undue impact on the other portions of the system.

For these ideas to be applicable to software systems, weneed a way to discuss the task that a software componentperforms, and separate this from the way in which thecomponent fulfills this responsibility.

Page 21: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ENCAPSULATION AND INTERCHANGEABILITY III

CATALOG

When the number of components in a system becomes large itis often useful to organize the items by means of a catalog. Weuse many di erent forms of catalog in everyday life. Examplesinclude a telephone directory, a dictionary, or an internet searchengine. Similarly, there are a variety of di erent catalogs used insoftware. One example is a simple list of classes. Anothercatalog might be the list of methods defined by a class. Areference book that describes the classes found in the Javastandard library is a very useful form of catalog. In each ofthese cases the idea is to provide the user a mechanism toquickly locate a single part (be it class, object, or method) froma larger collection of items.

Page 22: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

INTERFACE AND IMPLEMENTATION I

In software we use the terms interface and implementationto describe the distinction between the what aspects of atask, and the how features; between the outside view, andthe inside view.An interface describes what a system is designed to do.This is the view that users of the abstraction mustunderstand.The interface says nothing about how the assigned task isbeing performed.So to work, an interface is matched with an implementationthat completes the abstraction.The designers of an engine will deal with the interface tothe transmission, while the designers of the transmissionmust complete an implementation of this interface.

Page 23: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

INTERFACE AND IMPLEMENTATION II

Similarly, a key step along the path to developing complexcomputer systems will be the division of a task intocomponent parts.These parts can then be developed by di erent members ofa team. Each component will have two faces, the interfacethat it shows to the outside world, and an implementationthat it uses to fulfill the requirements of the interface.The division between interface and implementation notonly makes it easier to understand a design at a high level(since the description of an interface is much simpler thanthe description of any specific implementation), but alsomake possible the interchangeability of softwarecomponents (as I can use any implementation thatsatisfies the specifications given by the interface).

Page 24: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

THE SERVICE VIEW I

The idea that an interface describes the service providedby a software component without describing thetechniques used to implement the service is at the heart ofa much more general approach to managing theunderstanding of complex software systems.

Each member of the community is providing a service thatis used by other members of the group.

No member could solve the problem on their own, and it isonly by working together that the desired outcome isachieved.

Page 25: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

THE SERVICE VIEW II

class Box { / / a box i s a new data type. . .private i n t value ; / / b u i l t out o f e x i s t i n g data type}

More examples: How ser interface libraries facilitate thecreation of windows.

A window is made of buttons, sliders, frames, panes andpanels.

Page 26: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

COMPOSITION I

The idea is to begin with a few primitive forms, and addrules for combining forms to create new forms.The key insight in composition is to permit the combinationmechanism to be used both on the new forms as well asthe original primitive forms.Examples: Regular expressions, type systems.We begin with the primitive types, such as int and boolean.The idea of a class then permits the user to create newtypes.These new types can include data fields constructed out ofprevious types, either primitive or user-defined.Since classes can build on previously defined classes, verycomplex structure can be constructed piece by piece.

Page 27: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF SPECIALIZATION I

Yet another approach to dealing with complexity is tostructure abstraction using layers of specialization.This is sometimes referred to as a taxonomy.For example, in biology we divide living things into animalsand plants.Living things are then divided into vertebrates andinvertebrates.Vertebrates eventually includes mammals, which can bedivided into (among other categories) cats and dogs, andso on.The key difference between this and the earlier abstractionis that the more specialized layers of abstraction (forexample, a cat) is indeed a representative of the moregeneral layer of abstraction (for example, an animal).

Page 28: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF SPECIALIZATION II

This was not true when, in an earlier example, wedescended from the characterization of a muscle to thedescription of di erent chemical interactions.

These two different types of relations are sometimesdescribed using the heuristic keywords “is-a” and “has-a”.

The first relationship, that of parts to a whole, is a has-arelation, as in the sentence “a car has an engine”.

In contrast, the specialization relation is described usingis-a, as in “a cat is a mammal”.

Page 29: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

LAYERS OF SPECIALIZATION III

NON-STANDARD BEHAVIOR

Phyl and his friends remind us that there are almost nevergeneralizations with- out their being exceptions. A platypus(such as phyl) is a mammal that lays eggs. Thus, while wemight associate the tidbit of knowledge “gives birth to liveyoung” with the category Mammal , we then need to amend thiswith the caveat “lays eggs” when we descend to the categoryPlatypus.Object-oriented languages will also need a mechanism tooverride information inherited from a more general category.We will explore this in more detail once we have developed theidea of class hierarchies.

Page 30: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

PATTERNS I

When faced with a new problem, most people will first lookto previous problems they have solved that seem to havecharacteristics in common with the new task.These previous problems can be used as a model, and thenew problem attacked in a similar fashion, making changesas necessary to fit the different circumstances.This insight lies behind the idea of a software pattern.A pattern is nothing more than an attempt to document aproven solution to a problem so that future problems canbe more easily handled in a similar fashion.In the object-oriented world this idea has been used largelyto describe patterns of interaction between the variousmembers of an object community.Example: Network proxy.

Page 31: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

PATTERNS II

A proxy handles all aspects of data communicationbetween the client and a server without each of themknowing the details of the network protocols.

Page 32: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

A SHORT HISTORY OF ABSTRACTION MECHANISMS I

Assembly language.Assembler hides how computations are done.The user communicates with the machines with opcodes.Procedures.Procedures and functions represent the next improvementin abstraction in programming langauges.Procedures allowed tasks that were executed repeatedly,or executed with only slight variations, to be collected inone place and reused rather than being duplicated severaltimes.In addition, the procedure gave the rst possibility forinformation hiding.

Page 33: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

A SHORT HISTORY OF ABSTRACTION MECHANISMS II

One programmer could write a procedure, or a set ofprocedures, that was used by many others.

Other programmers did not need to know the exact detailsof the implementation.

They needed only the necessary interface.

But procedures were not an answer to all problems.

In particular, they were not an effective mechanism forinformation hiding, and they only partially solved theproblem of multiple programmers making use of the samenames.

Page 34: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

MODULES I

The solution to the problem of global name spacecongestion was the introduction of the idea of a module.In one sense, modules can be viewed simply as animproved technique for creating and managing collectionsof names and their associated values.Our stack example is typical, in that there is someinformation (the interface routines) that we want to bewidely and publicly available, whereas there are other datavalues (the stack data themselves) that we want restricted.Stripped to its barest form, a module provides the ability todivide a name space into two parts.The public part is accessible outside the module; theprivate part is accessible only within the module.

Page 35: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ABSTRACT DATA TYPES I

Programmers should be able to de ne their own new dataabstractions that work much like the primitive systemprovided data types.This includes giving clients the ability to create multipleinstances of the data type.But equally important, clients should be able to use theseinstances knowing only the operations that have beenprovided, without concern for how those operations weresupported.An abstract data type is defined by an abstractspecification.The specification for our stack data type might list, forexample, the trio of operations push, pop and top.

Page 36: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ABSTRACT DATA TYPES II

Matched with the ADT will be one or more differentimplementations.There might be several di erent implementation techniquesfor our stack; for example one using an array and anotherusing a linked list.As long as the programmer restricts themselves to only theabstract speci cation, any valid implementation shouldwork equally well.The important advance in the idea of the ADT is to finallyseparate the notions of interface and implementation.Modules are frequently used as an implementationtechnique for abstract data types, although we emphasizethat modules are an implementation technique and that theabstract data type is a more theoretical concept.

Page 37: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ABSTRACT DATA TYPES III

The two are related but are not identical.To build an abstract data type, we must be able to:

1 Export a type de nition.2 Make available a set of operations that can be used to

manipulate instances of the type.3 Protect the data associated with the type so that they can

be operated on only by the provided routines.4 Make multiple instances of the type.

As we have defined them, modules serve only as aninformation-hiding mechanism and thus directly addressonly list items 2 and 3, although the others can beaccommodated via appropriate programming techniques.Packages , found in languages such as CLU and Ada, arean attempt to address more directly the issues involved indefining abstract data types.

Page 38: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

ABSTRACT DATA TYPES IV

In a certain sense, an object is simply an abstract datatype.

People have said, for example, that Smalltalk programmerswrite the most “structured” of all programs because theycannot write anything but defnitions of abstract data types.

It is true that an object definition is an abstract data type,but the notions of object-oriented programming build on theideas of abstract data types and add to them importantinnovations in code sharing and reusability.

Page 39: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

A SERVICE CENTERED VIEW I

Assembly language and procedures as abstractionmechanisms concentrated the programmers view at thefunctional level how a task should be accomplished.The movement towards modules and ADT are indicative ofa shift from a function-centered conception of computationto a more data-centered view.Here it is the data values that are important, theirstructure,representation and manipulation.Object-oriented programming starts from thisdata-centered view of the world and takes it one stepfurther.It is not that data abstractions, per se, are important tocomputation.

Page 40: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

A SERVICE CENTERED VIEW II

Rather, an ADT is a useful abstraction because it can bedefined in terms of the service it o ers to the rest of aprogram.

Other types of abstractions can be similarly de ned, not interms of their particular actions or their data values, but interms of the services they provide.

Thus, object-oriented programming represents a third stepin this sequence.

From function centered, to data centered, and finally toservice centered view of how to structure a computerprogram.

Page 41: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

MESSAGES, INHERITANCE AND POLYMORPHISM I

In addition to this service-centered view of computing,object-oriented programming adds several important newideas to the concept of the abstract data type.Foremost among these is message passing . Activity isinitiated by a request to a specific object, not by theinvoking of a function.Implicit in message passing is the idea that theinterpretation of a message can vary with di erent objects.That is, the behavior and response that the message elicitwill depend upon the object receiving it.Thus, push can mean one thing to a stack, and a very dierent thing to a mechanical-arm controller.

Page 42: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

MESSAGES, INHERITANCE AND POLYMORPHISM II

Since names for operations need not be unique, simpleand direct forms can be used, leading to more readableand understandable code.Finally, object-oriented programming adds themechanisms of inheritance and polymorphism.Inheritance allows di erent data types to share the samecode, leading to a reduction in code size and an increasein functionality.Polymorphism allows this shared code to be tailored to thespecific circumstances of individual data types.The emphasis on the independence of individualcomponents permits an incremental development processin which individual software units are designed,programmed, and tested before being combined into alarge system.

Page 43: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

SUMMARY I

People deal with complex artifacts and situations every day.Thus, while many readers may not yet have createdcomplex computer programs, they nevertheless will haveexperience in using the tools that computer scientistsemploy in managing complexity.The most basic tool is abstraction, the purposefulsuppression of detail in order to emphasize a few basicfeatures.Information hiding describes the part of abstraction inwhich we intentionally choose to ignore some features sothat we can concentrate on others.Abstraction is often combined with a division intocomponents.

Page 44: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

SUMMARY II

For example, we divided the automobile into the engineand the transmission.Components are carefully chosen so that they encapsulatecertain key features, and interact with other componentsthrough a simple and xed interface .The division into components means we can divide a largetask into smaller problems that can then be worked onmore-or-less independently of each other.It is the responsibility of a developer of a component toprovide an implementation that satis es the requirementsof the interface.A point of view that turns out to be very useful indeveloping complex software system is the concept of aservice provider.

Page 45: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

SUMMARY III

A software component is providing a service to othercomponents with which it interacts.In real life we often characterize members of thecommunities in which we operate by the services theyprovide.A delivery person is charged with transporting owers froma orist to a recipient.Thus this metaphor allows one to think about a largesoftware system in the same way that we think aboutsituations in our everyday lives.Another form of abstraction is a taxonomy, inobject-oriented languages more often termed aninheritance hierarchy.

Page 46: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

SUMMARY IV

The layers are more detailed representatives of a generalcategory.

An example of this type of system is a biological divisioninto categories such as Living Thing-Animal- Mammal-Cat.

Each level is a more specialized version of the previous.

This division simpli es understanding, since knowledge ofmore general levels is applicable to many more speci ccategories.

When applied to software this technique also simplifies thecreation of new components, since if a new componentcan be related to an existing category all the functionalityof the older category can be used for free.

Page 47: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

SUMMARY V

Thus, for example, by saying that a new componentrepresents a Frame in the Java library we immediately getfeatures such as a menu bar, as well as the ability to moveand resize the window.Finally, a particular tool that has become popular in recentyears is the pattern.A pattern is simply a generalized description of a solutionto a problem that has been observed to occur in manyplaces and in many forms.The pattern described how the problem can be addressed,and the reasons both for adopting the solution and forconsidering other alternatives.

Page 48: Abstraction

Introduction Layers of Abstraction Other Forms of Abstraction A Short History of Abstraction Mechanisms Summary References

REFERENCES I

Contents of this lesson are taken from the following book.

An Introduction to Object Oriented Programming, TimothyBudd.