Preface Bonthe ice-blue waters of the festooned Norwegian coast amplified (by aberration of world currents,for which marine geographers have yet to find a suitable explanation)along the much grayer range of the Californian Pacific;viewed by some as a typhoon,by some as a tsunami,and by some as a storm in a teacup-a tidal wave is hitting the shores of the computing world. "Object-oriented"is the latest in term,complementing and in many cases replacing “structured”as the high-tech version of“good”.As is inevitable in such a case,the term is used by different people with different meanings;just as inevitable is the well-known three-step sequence of reactions that meets the introduction of a new methodological principle:(I)“it's trivial",(2)“it cannot work,(3)“that's how I did it all along anyway'”. (The order may vary.) Let us have this clear right away,lest the reader think the author takes a half-hearted approach to his topic:I do not see the object-oriented method as a mere fad;I think it is not trivial (although I shall strive to make it as limpid as I can);I know it works;and I believe it is not only different from but even,to a certain extent,incompatible with the techniques that most people still use today-including some of the principles taught in many software engineering textbooks.I further believe that object technology holds the potential for fundamental changes in the software industry,and that it is here to stay Finally,I hope that as the reader progresses through these pages,he will share some of my excitement about this promising avenue to software analysis,design and implementation. "Avenue to software analysis,design and implementation".To present the object- oriented method,this books resolutely takes the viewpoint of software engineering-of the methods,tools and techniques for developing quality software in production environments.This is not the only possible perspective,as there has also been interest in applying object-oriented principles to such areas as exploratory programming and artificial intelligence.Although the presentation does not exclude these applications,they are not its main emphasis.Our principal goal in this discussion is to study how practicing software developers,in industrial as well as academic environments,can use object technology to improve (in some cases dramatically)the quality of the software they produce
Preface Born in the ice-blue waters of the festooned Norwegian coast; amplified (by an aberration of world currents, for which marine geographers have yet to find a suitable explanation) along the much grayer range of the Californian Pacific; viewed by some as a typhoon, by some as a tsunami, and by some as a storm in a teacup — a tidal wave is hitting the shores of the computing world. “Object-oriented” is the latest in term, complementing and in many cases replacing “structured” as the high-tech version of “good”. As is inevitable in such a case, the term is used by different people with different meanings; just as inevitable is the well-known three-step sequence of reactions that meets the introduction of a new methodological principle: (1) “it’s trivial”; (2) “it cannot work”; (3) “that’s how I did it all along anyway”. (The order may vary.) Let us have this clear right away, lest the reader think the author takes a half-hearted approach to his topic: I do not see the object-oriented method as a mere fad; I think it is not trivial (although I shall strive to make it as limpid as I can); I know it works; and I believe it is not only different from but even, to a certain extent, incompatible with the techniques that most people still use today — including some of the principles taught in many software engineering textbooks. I further believe that object technology holds the potential for fundamental changes in the software industry, and that it is here to stay. Finally, I hope that as the reader progresses through these pages, he will share some of my excitement about this promising avenue to software analysis, design and implementation. “Avenue to software analysis, design and implementation”. To present the objectoriented method, this books resolutely takes the viewpoint of software engineering — of the methods, tools and techniques for developing quality software in production environments. This is not the only possible perspective, as there has also been interest in applying object-oriented principles to such areas as exploratory programming and artificial intelligence. Although the presentation does not exclude these applications, they are not its main emphasis. Our principal goal in this discussion is to study how practicing software developers, in industrial as well as academic environments, can use object technology to improve (in some cases dramatically) the quality of the software they produce
vi PREFACE Structure,reliability,epistemology and classification Object technology is at its core the combination of four ideas:a structuring method,a reliability discipline,an epistemological principle and a classification technique. The structuring method applies to software decomposition and reuse.Software systems perform certain actions on objects of certain types;to obtain flexible and reusable systems,it is better to base their structure on the object types than on the actions.The resulting concept is a remarkably powerful and versatile mechanism called the class, which in object-oriented software construction serves as the basis for both the modular structure and the type system. The reliability discipline is a radical approach to the problem of building software that does what it is supposed to do.The idea is to treat any system as a collection of components which collaborate the way successful businesses do:by adhering to contracts defining explicitly the obligations and benefits incumbent on each party. The epistemological principle addresses the question of how we should describe the Abstract data rypes classes.In object technology,the objects described by a class are only defined by what we are discussed in chapter 6.which can do with them:operations (also known as features)and formal properties of these also addresses some operations(the contracts).This idea is formally expressed by the theory of abstract data of the related episte- types,covered in detail in a chapter of this book.It has far-reaching implications,some mological issues. going beyond software,and explains why we must not stop at the naive concept of "object"borrowed from the ordinary meaning of that word.The tradition of information systems modeling usually assumes an"external reality"that predates any program using it;for the object-oriented developer,such a notion is meaningless,as the reality does not exist independently of what you want to do with it.(More precisely whether it exists or not is an irrelevant question,as we only know what we can use,and what we know of something is defined entirely by how we can use it. The classification technigue follows from the observation that systematic intellectual work in general and scientific reasoning in particular require devising taxonomies for the domains being studied.Software is no exception,and the object- oriented method relies heavily on a classification discipline known as inheritance. Simple but powerful The four concepts of class,contract,abstract data type and inheritance immediately raise a number of questions.How do we find and describe classes?How should our programs manipulate classes and the corresponding objects(the instances of these classes)?What are the possible relations between classes?How can we capitalize on the commonalities that may exist between various classes?How do these ideas relate to such key software engineering concerns as extendibility,ease of use and efficiency? Answers to these questions rely on a small but powerful array of techniques for producing reusable,extendible and reliable software:polymorphism and dynamic binding;a new view of types and type checking;genericity,constrained and
vi PREFACE Structure, reliability, epistemology and classification Object technology is at its core the combination of four ideas: a structuring method, a reliability discipline, an epistemological principle and a classification technique. The structuring method applies to software decomposition and reuse. Software systems perform certain actions on objects of certain types; to obtain flexible and reusable systems, it is better to base their structure on the object types than on the actions. The resulting concept is a remarkably powerful and versatile mechanism called the class, which in object-oriented software construction serves as the basis for both the modular structure and the type system. The reliability discipline is a radical approach to the problem of building software that does what it is supposed to do. The idea is to treat any system as a collection of components which collaborate the way successful businesses do: by adhering to contracts defining explicitly the obligations and benefits incumbent on each party. The epistemological principle addresses the question of how we should describe the classes. In object technology, the objects described by a class are only defined by what we can do with them: operations (also known as features) and formal properties of these operations (the contracts). This idea is formally expressed by the theory of abstract data types, covered in detail in a chapter of this book. It has far-reaching implications, some going beyond software, and explains why we must not stop at the naïve concept of “object” borrowed from the ordinary meaning of that word. The tradition of information systems modeling usually assumes an “external reality” that predates any program using it; for the object-oriented developer, such a notion is meaningless, as the reality does not exist independently of what you want to do with it. (More precisely whether it exists or not is an irrelevant question, as we only know what we can use, and what we know of something is defined entirely by how we can use it.) The classification technique follows from the observation that systematic intellectual work in general and scientific reasoning in particular require devising taxonomies for the domains being studied. Software is no exception, and the objectoriented method relies heavily on a classification discipline known as inheritance. Simple but powerful The four concepts of class, contract, abstract data type and inheritance immediately raise a number of questions. How do we find and describe classes? How should our programs manipulate classes and the corresponding objects (the instances of these classes)? What are the possible relations between classes? How can we capitalize on the commonalities that may exist between various classes? How do these ideas relate to such key software engineering concerns as extendibility, ease of use and efficiency? Answers to these questions rely on a small but powerful array of techniques for producing reusable, extendible and reliable software: polymorphism and dynamic binding; a new view of types and type checking; genericity, constrained and Abstract data types are discussed in chapter 6, which also addresses some of the related epistemological issues
PREFACE vii unconstrained;information hiding;assertions;safe exception handling;automatic garbage collection.Efficient implementation techniques have been developed which permit applying these ideas successfully to both small and large projects under the tight constraints of commercial software development.Object-oriented techniques have also had a considerable impact on user interfaces and development environments,making it possible to produce much better interactive systems than was possible before.All these important ideas will be studied in detail,so as to equip the reader with tools that are immediately applicable to a wide range of problems. Organization of the text In the pages that follow we will review the methods and techniques of object-oriented software construction.The presentation has been divided into six parts. Chapters I to 2. Part A is an introduction and overview.It starts by exploring the fundamental issue of software quality and continues with a brief survey of the method's main technical characteristics.This part is almost a little book by itself,providing a first view of the object-oriented approach for hurried readers. Chapters 3 to 6. Part B is not hurried.Entitled "The road to object orientation",it takes the time to describe the methodological concems that lead to the central O-O concepts.Its focus is on modularity:what it takes to devise satisfactory structures for "in-the-large"system construction.It ends with a presentation of abstract data types,the mathematical basis for object technology.The mathematics involved is elementary,and less mathematically inclined readers may content themselves with the basic ideas,but the presentation provides the theoretical background that you will need for a full understanding of O-O principles and issues. Chapters 7 to 18. Part C is the technical core of the book.It presents,one by one,the central technical components of the method:classes;objects and the associated run-time model;memory management issues;genericity and typing;design by contract,assertions,exceptions; inheritance,the associated concepts of polymorphism and dynamic binding,and their many exciting applications. Chapters 19 to 29. Part D discusses methodology,with special emphasis on analysis and design. Through several in-depth case studies,it presents some fundamental design patterns,and covers such central questions as how to find the classes,how to use inheritance properly, and how to design reusable libraries.It starts with a meta-level discussion of the intellectual requirements on methodologists and other advice-givers;it concludes with a review of the software process (the lifecycle model)for O-0 development and a discussion of how best to teach the method in both industry and universities. Chapters 30 to 32. Part E explores advanced topics:concurrency,distribution,client-server development and the Internet;persistence,schema evolution and object-oriented databases;the design of interactive systems with modern("GUI")graphical interfaces
PREFACE vii unconstrained; information hiding; assertions; safe exception handling; automatic garbage collection. Efficient implementation techniques have been developed which permit applying these ideas successfully to both small and large projects under the tight constraints of commercial software development. Object-oriented techniques have also had a considerable impact on user interfaces and development environments, making it possible to produce much better interactive systems than was possible before. All these important ideas will be studied in detail, so as to equip the reader with tools that are immediately applicable to a wide range of problems. Organization of the text In the pages that follow we will review the methods and techniques of object-oriented software construction. The presentation has been divided into six parts. Part A is an introduction and overview. It starts by exploring the fundamental issue of software quality and continues with a brief survey of the method’s main technical characteristics. This part is almost a little book by itself, providing a first view of the object-oriented approach for hurried readers. Part B is not hurried. Entitled “The road to object orientation”, it takes the time to describe the methodological concerns that lead to the central O-O concepts. Its focus is on modularity: what it takes to devise satisfactory structures for “in-the-large” system construction. It ends with a presentation of abstract data types, the mathematical basis for object technology. The mathematics involved is elementary, and less mathematically inclined readers may content themselves with the basic ideas, but the presentation provides the theoretical background that you will need for a full understanding of O-O principles and issues. Part C is the technical core of the book. It presents, one by one, the central technical components of the method: classes; objects and the associated run-time model; memory management issues; genericity and typing; design by contract, assertions, exceptions; inheritance, the associated concepts of polymorphism and dynamic binding, and their many exciting applications. Part D discusses methodology, with special emphasis on analysis and design. Through several in-depth case studies, it presents some fundamental design patterns, and covers such central questions as how to find the classes, how to use inheritance properly, and how to design reusable libraries. It starts with a meta-level discussion of the intellectual requirements on methodologists and other advice-givers; it concludes with a review of the software process (the lifecycle model) for O-O development and a discussion of how best to teach the method in both industry and universities. Part E explores advanced topics: concurrency, distribution, client-server development and the Internet; persistence, schema evolution and object-oriented databases; the design of interactive systems with modern (“GUI”) graphical interfaces. Chapters 1 to 2. Chapters 3 to 6. Chapters 7 to 18. Chapters 19 to 29. Chapters 30 to 32
viii PREFACE Part F is a review of how the ideas can be implemented,or in some cases emulated, Chapters 33 to 35. in various languages and environments.This includes in particular a discussion of major object-oriented languages,focusing on Simula,Smalltalk,Objective-C,C++,Ada 95 and Java,and an assessment of how to obtain some of the benefits ofobject orientation in such non-O-O languages as Fortran,Cobol,Pascal,C and Ada. Part G(doing it right)describes an environment which goes beyond these solutions Chapter 36. and provides an integrated set of tools to support the ideas of the book. As complementary reference material,an appendix shows some important reusable Appendix A. library classes discussed in the text,providing a model for the design of reusable software. A Book-Wide Web It can be amusing to see authors taking pains to describe recommended paths through their books,sometimes with the help of sophisticated traversal charts-as if readers ever paid any attention,and were not smart enough to map their own course.An author is permitted, however,to say in what spirit he has scheduled the different chapters,and what path he had in mind for what Umberto Eco calls the Model Reader-not to be confused with the real reader,also known as "you",made of flesh,blood and tastes. The answer here is the simplest possible one.This book tells a story,and assumes that the Model Reader will follow that story from beginning to end,being however invited to avoid the more specialized sections marked as "skippable on first reading"and,if not mathematically inclined,to ignore a few mathematical developments also labeled explicitly.The real reader,of course,may want to discover in advance some of the plot's later developments,or to confine his attention to just a few subplots;every chapter has for that reason been made as self-contained as possible,so that you should be able to intake the material at the exact dosage which suits you best. Because the story presents a coherent view of software development,its successive topics are tightly intertwined.The margin notes offer a subtext of cross references,a Book-Wide Web linking the various sections back and forth.My advice to the Model Reader is to ignore them on first reading,except as a reassurance that questions which at some stage are left partially open will be fully closed later on.The real reader,who may not want any advice,might use the cross references as unofficial guides when he feels like cheating on the prearranged order of topics. Both the Model Reader and the real reader should find the cross references mostly useful in subsequent readings,to make sure that they have mastered a certain object- oriented concept in depth,and understood its connections with the method's other components.Like the hyperlinks of a WWW document,the cross references should make it possible to follow such associations quickly and effectively. The CD-ROM that accompanies this book and contains all of its text provides a See"bou the convenient way to follow cross references:just click on them.All the cross references accompanying CD. have been preserved. ROM".page xiv
viii PREFACE Part F is a review of how the ideas can be implemented, or in some cases emulated, in various languages and environments. This includes in particular a discussion of major object-oriented languages, focusing on Simula, Smalltalk, Objective-C, C++, Ada 95 and Java, and an assessment of how to obtain some of the benefits of object orientation in such non-O-O languages as Fortran, Cobol, Pascal, C and Ada. Part G (doing it right) describes an environment which goes beyond these solutions and provides an integrated set of tools to support the ideas of the book. As complementary reference material, an appendix shows some important reusable library classes discussed in the text, providing a model for the design of reusable software. A Book-Wide Web It can be amusing to see authors taking pains to describe recommended paths through their books, sometimes with the help of sophisticated traversal charts — as if readers ever paid any attention, and were not smart enough to map their own course. An author is permitted, however, to say in what spirit he has scheduled the different chapters, and what path he had in mind for what Umberto Eco calls the Model Reader — not to be confused with the real reader, also known as “you”, made of flesh, blood and tastes. The answer here is the simplest possible one. This book tells a story, and assumes that the Model Reader will follow that story from beginning to end, being however invited to avoid the more specialized sections marked as “skippable on first reading” and, if not mathematically inclined, to ignore a few mathematical developments also labeled explicitly. The real reader, of course, may want to discover in advance some of the plot’s later developments, or to confine his attention to just a few subplots; every chapter has for that reason been made as self-contained as possible, so that you should be able to intake the material at the exact dosage which suits you best. Because the story presents a coherent view of software development, its successive topics are tightly intertwined. The margin notes offer a subtext of cross references, a Book-Wide Web linking the various sections back and forth. My advice to the Model Reader is to ignore them on first reading, except as a reassurance that questions which at some stage are left partially open will be fully closed later on. The real reader, who may not want any advice, might use the cross references as unofficial guides when he feels like cheating on the prearranged order of topics. Both the Model Reader and the real reader should find the cross references mostly useful in subsequent readings, to make sure that they have mastered a certain objectoriented concept in depth, and understood its connections with the method’s other components. Like the hyperlinks of a WWW document, the cross references should make it possible to follow such associations quickly and effectively. The CD-ROM that accompanies this book and contains all of its text provides a convenient way to follow cross references: just click on them. All the cross references have been preserved. Chapters 33 to 35. Chapter 36. Appendix A. See “About the accompanying CDROM”, page xiv
PREFACE The notation In software perhaps even more than elsewhere,thought and language are closely connected.As we progress through these pages,we will carefully develop a notation for expressing object-oriented concepts at all levels:modeling,analysis,design, implementation,maintenance. Here and everywhere else in this book,the pronoun "we"does not mean "the author":as in ordinary language,"we"means you and I-the reader and the author.In other words I would like you to expect that,as we develop the notation,you will be involved in the process. This assumption is not really true,of course,since the notation existed before you started reading these pages.But it is not completely preposterous either,because I hope that as we explore the object-oriented method and carefully examine its implications the supporting notation will dawn on you with a kind of inevitability,so that you will indeed feel that you helped design it. This explains why although the notation has been around for more than ten years and is in fact supported by several commercial implementations,including one from my company (ISE),I have downplayed it as a language.(Its name does appear in one place in the text,and several times in the bibliography.This book is about the object-oriented method for reusing,analyzing,designing,implementing and maintaining software;the language is an important and I hope natural consequence of that method,not an aim in itself. In addition,the language is straightforward and includes very little else than direct support for the method.First-year students using it have commented that it was"no language at all"-meaning that the notation is in one-to-one correspondence with the method:to learn one is to learn the other,and there is scant extra linguistic decoration on top of the concepts.The notation indeed shows few of the peculiarities (often stemming from historical circumstances,machine constraints or the requirement to be compatible with older formalisms)that characterize most of today's programming languages.Of course you may disagree with the choice of keywords (why do rather than begin or perhaps faire?),or would like to add semicolon terminators after each instruction.(The syntax has been designed so as to make semicolons optional.)But these are side issues. What counts is the simplicity of the notation and how directly it maps to the concepts.If you understand object technology,you almost know it already. Most software books take the language for granted,whether it is a programming language or a notation for analysis or design.Here the approach is different;involving the reader in the design means that one must not only explain the language but also justify it and discuss the alternatives.Most ofthe chapters of part C include a"discussion"section explaining the issues encountered during the design of the notation,and how they were resolved.I often wished,when reading descriptions of well-known languages,that the designers had told me not only what solutions they chose,but why they chose them,and what alternatives they rejected.The candid discussions included in this book should,I hope,provide you with insights not only about language design but also about software construction,as the two tasks are so strikingly similar
PREFACE ix The notation In software perhaps even more than elsewhere, thought and language are closely connected. As we progress through these pages, we will carefully develop a notation for expressing object-oriented concepts at all levels: modeling, analysis, design, implementation, maintenance. Here and everywhere else in this book, the pronoun “we” does not mean “the author”: as in ordinary language, “we” means you and I — the reader and the author. In other words I would like you to expect that, as we develop the notation, you will be involved in the process. This assumption is not really true, of course, since the notation existed before you started reading these pages. But it is not completely preposterous either, because I hope that as we explore the object-oriented method and carefully examine its implications the supporting notation will dawn on you with a kind of inevitability, so that you will indeed feel that you helped design it. This explains why although the notation has been around for more than ten years and is in fact supported by several commercial implementations, including one from my company (ISE), I have downplayed it as a language. (Its name does appear in one place in the text, and several times in the bibliography.) This book is about the object-oriented method for reusing, analyzing, designing, implementing and maintaining software; the language is an important and I hope natural consequence of that method, not an aim in itself. In addition, the language is straightforward and includes very little else than direct support for the method. First-year students using it have commented that it was “no language at all” — meaning that the notation is in one-to-one correspondence with the method: to learn one is to learn the other, and there is scant extra linguistic decoration on top of the concepts. The notation indeed shows few of the peculiarities (often stemming from historical circumstances, machine constraints or the requirement to be compatible with older formalisms) that characterize most of today’s programming languages. Of course you may disagree with the choice of keywords (why do rather than begin or perhaps faire?), or would like to add semicolon terminators after each instruction. (The syntax has been designed so as to make semicolons optional.) But these are side issues. What counts is the simplicity of the notation and how directly it maps to the concepts. If you understand object technology, you almost know it already. Most software books take the language for granted, whether it is a programming language or a notation for analysis or design. Here the approach is different; involving the reader in the design means that one must not only explain the language but also justify it and discuss the alternatives. Most of the chapters of part C include a “discussion” section explaining the issues encountered during the design of the notation, and how they were resolved. I often wished, when reading descriptions of well-known languages, that the designers had told me not only what solutions they chose, but why they chose them, and what alternatives they rejected. The candid discussions included in this book should, I hope, provide you with insights not only about language design but also about software construction, as the two tasks are so strikingly similar