1 Avoiding improper classes Active data structures Original - PDF document

Simplicity Programming in the Large Bertrand Meyer Lesson 16 Command / Query Separation principle: � Clear, understandable interfaces Systematic naming conventions Object-Oriented Design principles Operand / Option Separation: Designing for reuse � Dramatically simplified feature interfaces Last update: 7 June 2004 Chair of Softw are Engineering Chair of Softw are Engineering Programming in the Large, 2004 2 The EiffelMath routine Typical API in a traditional library (NAG) nonlinear_ode ... Set up the non-default values ... ( equation_count : in INTEGER ; epsilon : in out DOUBLE ; e . solve func : procedure ( eq_count : INTEGER ; a : DOUBLE ; eps : DOUBLE ; b : ARRAY [ DOUBLE ] ; ... Solve the problem, recording the answer in x and y ... cm : pointer Libtype ); left_count , coupled_count : INTEGER … ) [And so on. Altogether 19 arguments, including: � 4 in out values; � 3 arrays, used both as input and output; � 6 functions, each with 6 or 7 arguments, of which 2 or 3 arrays!] Chair of Softw are Engineering Chair of Softw are Engineering 3 Programming in the Large, 2004 4 Programming in the Large, 2004 The Consistency Principle Abstraction and objects All the components of a library should Not all classes describe “objects” in the sense of real-world things. proceed from an overall coherent design, Types of classes: and follow a set of systematic, explicit and � Analysis classes – examples: AIRPLANE, CUSTOMER, uniform conventions PARTICLE. � Design classes – examples: STATE, COMMAND, HANDLE . � Implementation classes – examples: ARRAY, LINKED_LIST . Two complementary aspects: More important than the notion of object is the concept of abstract data type (or “data abstraction”). � Top-down and deductive (“overall design”) Key to the construction of a good library is the search for the best abstractions. � Bottom-up and inductive (“conventions”) Chair of Softw are Engineering Chair of Softw are Engineering 5 Programming in the Large, 2004 6 Programming in the Large, 2004 1

Avoiding improper classes Active data structures Original interface for lists: A typical use: A few danger signals: j := l . search ( x ); l . insert ( i , x ) � A class whose name is a verb in the imperative form, l . insert ( j + 1, y ) l . remove ( i ) e.g. ANALYZE . (Exception: command classes.) pos : = l . search ( x ) � A class with no parent and just one exported routine. l . insert_left_of_value (… ) Number � A class that introduces or redeclares no feature. Perfect of l . insert_right_of_value (… ) (Purely taxonomical role only.) Features Desirable l . insert_by_position (… ) Beware of “TAXOMANIA” The revised interface: Number of (re)uses Queries: l . index l . item l . before l . after Commands: l . start l . forth l . finish l . back l . go ( i ) l . search ( x ) l . put ( x ) l.remove Chair of Softw are Engineering Chair of Softw are Engineering Programming in the Large, 2004 Programming in the Large, 2004 7 8 A list seen as an active data structure An object as machine: “iterators” before after item start item index forth 1 count before after back forth put_right index Chair of Softw are Engineering Chair of Softw are Engineering 9 Programming in the Large, 2004 10 Programming in the Large, 2004 Command-Query separation principle Referential transparency � A command (procedure) does something but does not If two expressions have equal value, we may substitute for return a result. the other in any context where that other is valid � A query (function or attribute) returns a result but does not change the state. If a = b , then f ( a ) = f ( b ) for any f . Prohibits functions with side effects. Changing a question shouldn’t change the answer Also: � For any integer i , normally i + i = 2 x i � But even if getint () = 2 , getint () + getint () This principle excludes many common schemes, such as is usually not equal to 4. using functions for input (e.g. C’s getint or equivalent). Chair of Softw are Engineering Chair of Softw are Engineering 11 Programming in the Large, 2004 12 Programming in the Large, 2004 2

Command-query separation A typical style Input mechanism (instead of n : = getint () ): your_object.perform_computation io . read_integer ok : = your_object.is_successful n : = io . last_integer if your_object.is_successful then value : = your_object.results end Chair of Softw are Engineering Chair of Softw are Engineering Programming in the Large, 2004 Programming in the Large, 2004 13 14 Solving Ax = b Libraries and assertions First attempt: Include as many visible assertions as possible: � Assertions help design the libraries right. if not A.singular then � Preconditions help find errors in client software. x : = solution ( A, b ) end � Library documentation fundamentally relies on assertions (interface forms). Better: APPLICATION l . insert ( x , j + k + 1) A.try_to_solve ( b ) insert ( x : G ; i : INTEGER ) if not A.was_singular then LIBRARY require x : = A.solution i >= 0 i <= count + 1 end Chair of Softw are Engineering Chair of Softw are Engineering 15 Programming in the Large, 2004 16 Programming in the Large, 2004 Designing for consistency: An example Designing for consistency Describing active structures properly: can after also be Typical iteration: before? from start until after loop some_action ( item ) Symmetry: not before forth before after not after end start finish forth back Conventions for an empty structure? item after before count � after must be true for the iteration to stop Valid cursor positions � For symmetry: before should be true too For symmetry and consistency, it is desirable to have the But this does not work for an empty structure ( count = 0, invariant properties: see invariant A): should index be 0 or 1? after = ( index = count + 1) A before = ( index = 0) Chair of Softw are Engineering Chair of Softw are Engineering 17 Programming in the Large, 2004 18 Programming in the Large, 2004 3

Designing for consistency Introducing sentinel items To obtain a consistent convention we may transform the Invariant (partial): invariant into: 0 < = index after = ( is_empty or ( index = count + 1)) index < = count + 1 before = ( index = 0) A’ B before = ( is_em pty or ( index = 0) after = ( index = count + 1) -- Hence: is_em pty = ( before and after ) not ( after and before ) not after ; not before before after Symmetric but leads to frequent tests of the form not after 1 <= index ; index <= count not before if after and not is_empty then ... instead of just 0 1 item count count + 1 if after then ... Valid cursor positions Chair of Softw are Engineering Chair of Softw are Engineering Programming in the Large, 2004 Programming in the Large, 2004 19 20 Non-empty structure The case of an empty structure not after ; not before before after not after 1 <= index ; index <= count 0 1 (i.e. count + 1) before after not after not before Valid cursor positions Chair of Softw are Engineering Chair of Softw are Engineering 21 Programming in the Large, 2004 22 Programming in the Large, 2004 Abstract preconditions Can after also be before? Lessons from the example General principles: Example (stacks): � Consistency � A posteriori: “How do I make this design decision compatible put is with the previous ones?”. � A priori: “How do I take this design decision so that it will be require easy – or at least possible – to make future ones compatible with it?”. not full � Use assertions, especially invariants, to clarify the do issues. … � Importance of symmetry concerns (cf. physics and ensure mathematics). … � Importance of limit cases (empty or full structures). end Chair of Softw are Engineering Chair of Softw are Engineering 23 Programming in the Large, 2004 24 Programming in the Large, 2004 4