1370 pág.

# Object Oriented Software Construction - Bertrand Meyer

Pré-visualização50 páginas

recorded once again in eld. Like the Hydra in its famous fight, the mailer kept growing a new head thought we had cut the last neck. repeating for the modern era the earlier feat of Hercules, we slew the beast hen we had removed more than twenty code extracts which all accessed, in other, information about the message sender. h the previous sections have only got us barely started on our road to abstract hould be clear by now that any program written in accordance with even the ary concepts of data abstraction would treat MAIL_MESSAGE as a carefully act notion, supporting a query operation, perhaps called sender, which ation about the message sender. Any portion of the mail program that needs on would obtain it solely through the sender query. Had the mail program d according to this seemingly obvious principle, it would have been the purpose of my little exercise, to modify the code of the sender query. e software would also then have provided an associated command operation update sender information, making the job even easier. the real moral of that little story (besides lowering the reader\u2019s guard in r the surprise mathematical offensive of the next section)? After all, the mail estion is successful, at least judging by its widespread use. But it typifies the y standard in the industry. Until we move significantly beyond that standard, ftware engineering\u201d will remain a case of wishful thinking. one more note. Some time after my brief encounter with the mail program, rtain network hackers had intruded into the computer systems of highly rnment laboratories, using a security hole of that very mail program \u2014 a hole miliar, so the press reported, to all those in the know. I was not in the know; arned the news, I was not surprised. ALIZING THE SPECIFICATION of data abstraction presented so far is too informal to be of durable use. in our staple example: a stack, as we now understand it, is defined in terms ble operations; but then we need to define these operations! l descriptions as above (put pushes an element \u201con top of\u201d the stack, remove ent \u201clast pushed\u201d and so on) do not suffice. We need to know precisely how ns can be used by clients, and what they will do for them. ABSTRACT DATA TYPES §6.4130 An abstract data type specification will provide this information. It consists of four paragraphs, explained in the next sections: \u2022 TYPES. \u2022 FUNCT \u2022 AXIOM \u2022 PRECO These p properties of The nota notation style \u2014 point for being co specifica Specifying The TYPES convenient to By the w developed in functions, ax objects, in th possible stack are not guilty able to refine \u201cset\u201d for \u201ctyp On one data type suc (the set of al modules of o on one partic sense. O-O de airplanes, all An obje an instance o STACK abstr over to objec explaining th IONS. S. NDITIONS. aragraphs will rely on a simple mathematical notation for specifying the an abstract data type (ADT for short). tion \u2014 a mathematical formalism, not to be confused with the software of the rest of this book even though for consistency it uses a similar syntactic has no name and is not a programming language; it could serve as the starting a formal specification language, but we shall not pursue this avenue here, ntent enough to use self-explanatory conventions for the unambiguous tion of abstract data types. types paragraph indicates the types being specified. In general, it may be specify several ADTs together, although our example has only one, STACK. ay, what is a type? The answer to this question will combine all the ideas the rest of this chapter; a type is a collection of objects characterized by ioms and preconditions. If for the moment you just view a type as a set of e mathematical sense of the word \u201cset\u201d \u2014 type STACK as the set of all s, type INTEGER as the set of all possible integer values and so on \u2014 you of any terrible misunderstanding. As you read this discussion you will be this view. In the meantime the discussion will not be too fussy about using e\u201d and conversely. point, however, you should make sure to avoid any confusion: an abstract h as STACK is not an object (one particular stack) but a collection of objects l stacks). Remember what our real goal is: finding a good basis for the ur software systems. As was noted in the previous chapter, basing a module ular object \u2014 one stack, one airplane, one bank account \u2014 would not make sign will enable us to build modules covering the properties of all stacks, all bank accounts \u2014 or at least of some stacks, airplanes or accounts. ct belonging to the set of objects described by an ADT specification is called f the ADT. For example, a specific stack which satisfies the properties of the act data type will be an instance of STACK. The notion of instance will carry t-oriented design and programming, where it will play an important role in e run-time behavior of programs. §6.4 FORMALIZING THE SPECIFICATION 131 The TYPES paragraph simply lists the types introduced in the specification. Here: Our spe objects of an Genericity In STACK [G parameter of The mechanis already encou It is po unjustified re accounts\u201d, \u201cs where they ex Writing them Reusability is we can make to represent th As a res obtain a dire ACCOUNT, parameter G. STACK is a fully defi generic type, The not principle, hav abstract data produce a gen right to use STACK specifying a elements are As this qualification. noted, is a ty STACK, for e TYPES \u2022 STACK [G] See \u201cGenericity\u201d, page 96. cification is about a single abstract data type STACK, describing stacks of arbitrary type G. ], G denotes an arbitrary, unspecified type. G is called a formal generic the abstract data type STACK, and STACK itself is said to be a generic ADT. m permitting such parameterized specifications is known as genericity; we ntered a similar concept in our review of package constructs. ssible to write ADT specifications without genericity, but at the price of petition. Why have separate specifications for the types \u201cstack of bank tack of integers\u201d and so on? These specifications would be identical except plicitly refer to the type of the stack elements \u2014 bank accounts or integers. , and then performing the type substitutions manually, would be tedious. desirable for specifications too \u2014 not just programs! Thanks to genericity, the type parameterization explicit by choosing some arbitrary name, here G, e variable type of stack elements. ult, an ADT such as STACK is not quite a type, but rather a type pattern; to ctly usable stack type, you must obtain some element type, for example and provide it as actual generic parameter corresponding to the formal So although STACK is by itself just a type pattern, the notation [ACCOUNT] ned type. Such a type, obtained by providing actual generic parameters to a is said to be generically derived. ions just seen are applicable recursively: every type should, at least in e an ADT specification, so you may view ACCOUNT as being itself an type; also, a type that you use as actual generic parameter to STACK (to erically derived type) may itself be generically derived, so it is perfectly all [STACK [ACCOUNT]] certain abstract data type: the instances of that type are stacks, whose themselves stacks; the elements of these latter stacks are bank accounts. example shows, the preceding definition of \u201cinstance\u201d needs some Strictly speaking, a particular stack is an instance not of STACK (which, as pe pattern rather than a type) but of some type generically derived from xample STACK [ACCOUNT]. It is convenient, however, to continue talking ABSTRACT DATA TYPES §6.4132 about instances of STACK and similar type patterns, with the understanding that this actually means instances