2 Criteria of object orientation n the previous chapter we explored the goals of the object-oriented method.As a preparation for parts B and C,in which we will discover the technical details of the method,it is useful to take a quick but wide glance at the key aspects of object-oriented development.Such is the aim of this chapter. One of the benefits will be to obtain a concise memento of what makes a system object-oriented.This expression has nowadays become so indiscriminately used that we need a list of precise properties under which we can assess any method,language or tool that its proponents claim to be O-O. This chapter limits its explanations to a bare minimum,so if this is your first reading you cannot expect to understand in detail all the criteria listed;explaining them is the task ofthe rest of the book.Consider this discussion a preview-not the real movie,just a trailer. Warning: Actually a warning is in order because unlike any good trailer this chapter is also SPOILER! what film buffs call a spoiler-it gives away some of the plot early.As such it breaks the step-by-step progression of this book,especially part B,which patiently builds the case for object technology by looking at issue after issue before deducing and justifying the solutions.If you like the idea of reading a broad overview before getting into more depth, this chapter is for you.But if you prefer not to spoil the pleasure of seeing the problems unfold and of discovering the solutions one by one,then you should simply skip it.You will not need to have read it to understand subsequent chapters. 2.1 ON THE CRITERIA Let us first examine the choice of criteria for assessing objectness. How dogmatic do we need to be? The list presented below includes all the facilities which I believe to be essential for the production of quality software using the object-oriented method.It is ambitious and may appear uncompromising or even dogmatic.What conclusion does this imply for an environment which satisfies some but not all of these conditions?Should one just reject such a half-hearted O-O environment as totally inadequate?
2 Criteria of object orientation In the previous chapter we explored the goals of the object-oriented method. As a preparation for parts B and C, in which we will discover the technical details of the method, it is useful to take a quick but wide glance at the key aspects of object-oriented development. Such is the aim of this chapter. One of the benefits will be to obtain a concise memento of what makes a system object-oriented. This expression has nowadays become so indiscriminately used that we need a list of precise properties under which we can assess any method, language or tool that its proponents claim to be O-O. This chapter limits its explanations to a bare minimum, so if this is your first reading you cannot expect to understand in detail all the criteria listed; explaining them is the task of the rest of the book. Consider this discussion a preview — not the real movie, just a trailer. Actually a warning is in order because unlike any good trailer this chapter is also what film buffs call a spoiler — it gives away some of the plot early. As such it breaks the step-by-step progression of this book, especially part B, which patiently builds the case for object technology by looking at issue after issue before deducing and justifying the solutions. If you like the idea of reading a broad overview before getting into more depth, this chapter is for you. But if you prefer not to spoil the pleasure of seeing the problems unfold and of discovering the solutions one by one, then you should simply skip it. You will not need to have read it to understand subsequent chapters. 2.1 ON THE CRITERIA Let us first examine the choice of criteria for assessing objectness. How dogmatic do we need to be? The list presented below includes all the facilities which I believe to be essential for the production of quality software using the object-oriented method. It is ambitious and may appear uncompromising or even dogmatic. What conclusion does this imply for an environment which satisfies some but not all of these conditions? Should one just reject such a half-hearted O-O environment as totally inadequate? Warning: SPOILER!
22 CRITERIA FOR OBJECT ORIENTATION $2.2 Only you,the reader,can answer this question relative to your own context.Several reasons suggest that some compromises may be necessary: "Object-oriented"is not a boolean condition:environment A,although not 100% O-O,may be"more"O-O than environment B;so if external constraints limit your choice to A and B you will have to pick A as the least bad object-oriented choice. Not everyone will need all of the properties all the time. Object orientation may be just one of the factors guiding your search for a software solution,so you may have to balance the criteria given here with other considerations. All this does not change the obvious:to make informed choices,even if practical constraints impose less-than-perfect solutions,you need to know the complete picture,as provided by the list below. Categories The set of criteria which follows has been divided into three parts: Method and language:these two almost indistinguishable aspects cover the thought processes and the notations used to analyze and produce software.Be sure to note that (especially in object technology)the term "language"covers not just the programming language in a strict sense,but also the notations,textual or graphical, used for analysis and design. Implementation and environment:the criteria in this category describe the basic properties of the tools which allow developers to apply object-oriented ideas. Libraries:object technology relies on the reuse of software components.Criteria in this category cover both the availability of basic libraries and the mechanisms needed to use libraries and produce new ones. This division is convenient but not absolute,as some criteria straddle two or three of the categories.For example the criterion labeled "memory management"has been classified under method and language because a language can support or prevent automatic garbage collection,but it also belongs to the implementation and environment category;the"assertion"criterion similarly includes a requirement for supporting tools. 2.2 METHOD AND LANGUAGE The first set of criteria covers the method and the supporting notation. Seamlessness The object-oriented approach is ambitious:it encompasses the entire software lifecycle. When examining object-oriented solutions,you should check that the method and language,as well as the supporting tools,apply to analysis and design as well as implementation and maintenance.The language,in particular,should be a vehicle for thought which will help you through all stages of your work
22 CRITERIA FOR OBJECT ORIENTATION §2.2 Only you, the reader, can answer this question relative to your own context. Several reasons suggest that some compromises may be necessary: • “Object-oriented” is not a boolean condition: environment A, although not 100% O-O, may be “more” O-O than environment B; so if external constraints limit your choice to A and B you will have to pick A as the least bad object-oriented choice. • Not everyone will need all of the properties all the time. • Object orientation may be just one of the factors guiding your search for a software solution, so you may have to balance the criteria given here with other considerations. All this does not change the obvious: to make informed choices, even if practical constraints impose less-than-perfect solutions, you need to know the complete picture, as provided by the list below. Categories The set of criteria which follows has been divided into three parts: • Method and language: these two almost indistinguishable aspects cover the thought processes and the notations used to analyze and produce software. Be sure to note that (especially in object technology) the term “language” covers not just the programming language in a strict sense, but also the notations, textual or graphical, used for analysis and design. • Implementation and environment: the criteria in this category describe the basic properties of the tools which allow developers to apply object-oriented ideas. • Libraries: object technology relies on the reuse of software components. Criteria in this category cover both the availability of basic libraries and the mechanisms needed to use libraries and produce new ones. This division is convenient but not absolute, as some criteria straddle two or three of the categories. For example the criterion labeled “memory management” has been classified under method and language because a language can support or prevent automatic garbage collection, but it also belongs to the implementation and environment category; the “assertion” criterion similarly includes a requirement for supporting tools. 2.2 METHOD AND LANGUAGE The first set of criteria covers the method and the supporting notation. Seamlessness The object-oriented approach is ambitious: it encompasses the entire software lifecycle. When examining object-oriented solutions, you should check that the method and language, as well as the supporting tools, apply to analysis and design as well as implementation and maintenance. The language, in particular, should be a vehicle for thought which will help you through all stages of your work
$2.2 METHOD AND LANGUAGE 23 The result is a seamless development process,where the generality of the concepts and notations helps reduce the magnitude of the transitions between successive steps in the lifecycle. These requirements exclude two cases,still frequently encountered but equally unsatisfactory: The use of object-oriented concepts for analysis and design only,with a method and notation that cannot be used to write executable software. The use of an object-oriented programming language which is not suitable for analysis and design. In summary: An object-oriented language and environment,together with the supporting method,should apply to the entire lifecycle,in a way that minimizes the gaps between successive activities. Classes The object-oriented method is based on the notion of class.Informally,a class is a software element describing an abstract data type and its partial or total implementation. An abstract data type is a set of objects defined by the list of operations,or features, applicable to these objects,and the properties of these operations. The method and the language should have the notion of class as their central concept. Assertions The features of an abstract data type have formally specified properties,which should be reflected in the corresponding classes.Assertions-routine preconditions,routine postconditions and class invariants-play this role.They describe the effect of features on objects,independently of how the features have been implemented Assertions have three major applications:they help produce reliable software;they provide systematic documentation;and they are a central tool for testing and debugging object-oriented software. The language should make it possible to equip a class and its features with assertions(preconditions,postconditions and invariants),relying on tools to produce documentation out of these assertions and,optionally,monitor them at run time. In the society of software modules,with classes serving as the cities and instructions (the actual executable code)serving as the executive branch of government,assertions provide the legislative branch.We shall see below who takes care of the judicial system
§2.2 METHOD AND LANGUAGE 23 The result is a seamless development process, where the generality of the concepts and notations helps reduce the magnitude of the transitions between successive steps in the lifecycle. These requirements exclude two cases, still frequently encountered but equally unsatisfactory: • The use of object-oriented concepts for analysis and design only, with a method and notation that cannot be used to write executable software. • The use of an object-oriented programming language which is not suitable for analysis and design. In summary: Classes The object-oriented method is based on the notion of class. Informally, a class is a software element describing an abstract data type and its partial or total implementation. An abstract data type is a set of objects defined by the list of operations, or features, applicable to these objects, and the properties of these operations. Assertions The features of an abstract data type have formally specified properties, which should be reflected in the corresponding classes. Assertions — routine preconditions, routine postconditions and class invariants — play this role. They describe the effect of features on objects, independently of how the features have been implemented. Assertions have three major applications: they help produce reliable software; they provide systematic documentation; and they are a central tool for testing and debugging object-oriented software. In the society of software modules, with classes serving as the cities and instructions (the actual executable code) serving as the executive branch of government, assertions provide the legislative branch. We shall see below who takes care of the judicial system. An object-oriented language and environment, together with the supporting method, should apply to the entire lifecycle, in a way that minimizes the gaps between successive activities. The method and the language should have the notion of class as their central concept. The language should make it possible to equip a class and its features with assertions (preconditions, postconditions and invariants), relying on tools to produce documentation out of these assertions and, optionally, monitor them at run time
24 CRITERIA FOR OBJECT ORIENTATION $2.2 Classes as modules Object orientation is primarily an architectural technique:its major effect is on the modular structure of software systems. The key role here is again played by classes.A class describes not just a type of objects but also a modular unit.In a pure object-oriented approach: Classes should be the only modules. In particular,there is no notion of main program,and subprograms do not exist as independent modular units.(They may only appear as part of classes.)There is also no need for the"packages"of languages such as Ada,although we may find it convenient for management purposes to group classes into administrative units,called clusters. Classes as types The notion of class is powerful enough to avoid the need for any other typing mechanism: Every type should be based on a class. Even basic types such as INTEGER and REAL can be derived from classes;normally such classes will be built-in rather than defined anew by each developer. Feature-based computation In object-oriented computation,there is only one basic computational mechanism:given a certain object,which (because of the previous rule)is always an instance of some class, call a feature of that class on that object.For example,to display a certain window on a screen,you call the feature display on an object representing the window-an instance of class WINDOW.Features may also have arguments:to increase the salary of an employee e by n dollars,effective at date d,you call the feature raise on e,with n and d as arguments. Just as we treat basic types as predefined classes,we may view basic operations (such as addition of numbers)as special,predefined cases of feature call,a very general mechanism for describing computations: Feature call should be the primary computational mechanism A class which contains a call to a feature of a class C is said to be a client of C. Feature call is also known as message passing;in this terminology,a call such as the above will be described as passing to e the message"raise your pay",with arguments d and
24 CRITERIA FOR OBJECT ORIENTATION §2.2 Classes as modules Object orientation is primarily an architectural technique: its major effect is on the modular structure of software systems. The key role here is again played by classes. A class describes not just a type of objects but also a modular unit. In a pure object-oriented approach: In particular, there is no notion of main program, and subprograms do not exist as independent modular units. (They may only appear as part of classes.) There is also no need for the “packages” of languages such as Ada, although we may find it convenient for management purposes to group classes into administrative units, called clusters. Classes as types The notion of class is powerful enough to avoid the need for any other typing mechanism: Even basic types such as INTEGER and REAL can be derived from classes; normally such classes will be built-in rather than defined anew by each developer. Feature-based computation In object-oriented computation, there is only one basic computational mechanism: given a certain object, which (because of the previous rule) is always an instance of some class, call a feature of that class on that object. For example, to display a certain window on a screen, you call the feature display on an object representing the window — an instance of class WINDOW. Features may also have arguments: to increase the salary of an employee e by n dollars, effective at date d, you call the feature raise on e, with n and d as arguments. Just as we treat basic types as predefined classes, we may view basic operations (such as addition of numbers) as special, predefined cases of feature call, a very general mechanism for describing computations: A class which contains a call to a feature of a class C is said to be a client of C. Feature call is also known as message passing; in this terminology, a call such as the above will be described as passing to e the message “raise your pay”, with arguments d and n. Classes should be the only modules. Every type should be based on a class. Feature call should be the primary computational mechanism
$2.2 METHOD AND LANGUAGE 25 Information hiding When writing a class,you will sometimes have to include a feature which the class needs for internal purposes only:a feature that is part of the implementation of the class,but not of its interface.Others features of the class-possibly available to clients-may call the feature for their own needs;but it should not be possible for a client to call it directly. The mechanism which makes certain features unfit for clients'calls is called information hiding.As explained in a later chapter,it is essential to the smooth evolution of software systems. In practice,it is not enough for the information hiding mechanism to support exported features(available to all clients)and secret features (available to no client);class designers must also have the ability to export a feature selectively to a set of designated clients. It should be possible for the author of a class to specify that a feature is available to all clients,to no client,or to specified clients. An immediate consequence of this rule is that communication between classes should be strictly limited.In particular,a good object-oriented language should not offer any notion of global variable;classes will exchange information exclusively through feature calls,and through the inheritance mechanism. Exception handling Abnormal events may occur during the execution of a software system.In object-oriented computation,they often correspond to calls that cannot be executed properly,as a result of a hardware malfunction,of an unexpected impossibility (such as numerical overflow in an addition),or of a bug in the software. To produce reliable software,it is necessary to have the ability to recover from such situations.This is the purpose of an exception mechanism. The language should provide a mechanism to recover from unexpected abnormal situations. In the society of software systems,as you may have guessed,the exception mechanism is the third branch of government,the judicial system(and the supporting police force). Static typing When the execution of a software system causes the call of a certain feature on a certain object,how do we know that this object will be able to handle the call?(In message terminology:how do we know that the object can process the message?) To provide such a guarantee of correct execution,the language must be typed.This means that it enforces a few compatibility rules;in particular:
§2.2 METHOD AND LANGUAGE 25 Information hiding When writing a class, you will sometimes have to include a feature which the class needs for internal purposes only: a feature that is part of the implementation of the class, but not of its interface. Others features of the class — possibly available to clients — may call the feature for their own needs; but it should not be possible for a client to call it directly. The mechanism which makes certain features unfit for clients’ calls is called information hiding. As explained in a later chapter, it is essential to the smooth evolution of software systems. In practice, it is not enough for the information hiding mechanism to support exported features (available to all clients) and secret features (available to no client); class designers must also have the ability to export a feature selectively to a set of designated clients. An immediate consequence of this rule is that communication between classes should be strictly limited. In particular, a good object-oriented language should not offer any notion of global variable; classes will exchange information exclusively through feature calls, and through the inheritance mechanism. Exception handling Abnormal events may occur during the execution of a software system. In object-oriented computation, they often correspond to calls that cannot be executed properly, as a result of a hardware malfunction, of an unexpected impossibility (such as numerical overflow in an addition), or of a bug in the software. To produce reliable software, it is necessary to have the ability to recover from such situations. This is the purpose of an exception mechanism. In the society of software systems, as you may have guessed, the exception mechanism is the third branch of government, the judicial system (and the supporting police force). Static typing When the execution of a software system causes the call of a certain feature on a certain object, how do we know that this object will be able to handle the call? (In message terminology: how do we know that the object can process the message?) To provide such a guarantee of correct execution, the language must be typed. This means that it enforces a few compatibility rules; in particular: It should be possible for the author of a class to specify that a feature is available to all clients, to no client, or to specified clients. The language should provide a mechanism to recover from unexpected abnormal situations