Program Realisation 2 Today’s Topics • Unit testing, manual versus automated http://www.win.tue.nl/˜hemerik/2IP20/ • ADT relationships: Lecture 4 – Multiple implementations of the same ADT contract Kees Hemerik – Generalization, specialization, subtyping Tom Verhoe ff Technische Universiteit Eindhoven • Inheritance Faculteit Wiskunde en Informatica Software Engineering & Technology • Method binding (“polymorphism”) Feedback to T.Verhoeff@TUE.NL • virtual , override , abstract , as , is , protected � 2007, T. Verhoe ff @ TUE.NL c 1 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 2 Program Realization 2: Lecture 4 Quality of Submitted Bounded and Unbounded Queues Workflow for Development of ADT as Product Year 2005–2006 1. Describe and analyse requirements (informal) Assignment # Submissions # Incorrect % Incorrect 2. Design class interface (public methods, parameters, incl. types) Bounded Queue 52 ≥ 15 > 25% 3. Design contract (method pre/post, public invariants) Unbounded Queue 48 ≥ 19 > 40% 4. Design/implement unit tests (test driver) Year 2006–2007 5. Design internal representation (private fields, private invariants, abstraction function) Assignment # Submissions # Incorrect % Incorrect 6. Implement method bodies (incl. assertion checking) Bounded Queue 60 ≥ 9 15% 7. Execute unit tests Unbounded Queue 48 ≥ 18 > 35% � 2007, T. Verhoe ff @ TUE.NL c 3 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 4 Program Realization 2: Lecture 4
Unit Test for ADTs A Confession • Test for correct functionality ; input satisfies precondition – No exception → check the postcondition Various approaches exist that attempt to improve our ability to do modular design of complex software systems. – Exception → FAILURE This has led to many new language constructs and tools. • Test for correct checking ; input does not satisfy precondition The theoretical foundation for today’s topics is not mature. – Exception → check the kind of exception – No exception → FAILURE We treat some language mechanisms that can easily be abused. Use with care and discipline! History: goto statement How to design test cases : choosing inputs and checking outputs How to execute tests cases : manually or automatically via test driver � 2007, T. Verhoe ff @ TUE.NL c 5 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 6 Program Realization 2: Lecture 4 Liskov Substitutability Principle (LSP) for Types Liskov Substitutability Principle (LSP) for ADTs Type S is a subtype of type T , when The ‘ is a ’ relationship can also be defined for ADT contracts . any value of type S can be used in every place where ADT S to be a subtype of ADT T , when a value of type T is acceptable: Every S is a T . every operation p of T is an operation of S with the same † S can be viewed as a specialization of T . signature (parameters etc.), such that T can be viewed as a generalization of S . type • [ precondition of S.p ⇐ precondition of T.p ] PositiveInteger = 1 .. MaxInt; { the positive integers } Digit = ’0’ .. ’9’; { the digit characters } • [ postcondition of S.p ⇒ postcondition of T.p ] Every PositiveInteger is an Integer . N.B. S can have other operations besides those of T . Every Digit is a Char . � 2007, T. Verhoe ff @ TUE.NL c 7 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 8 Program Realization 2: Lecture 4
Subclasses in Object Pascal Inheritance: Substitutability Example class as module — class as type With each stored string, TStringList can store an associated TObject : TStringList.AddObject( const S: string ; AObject: TObject) type 1 type TParent = class (TObject) { descendant of TObject } TMyObject = class (TObject) 2 {...} {...} 3 end ; { class TParent } end ; { class TMyObject } 4 5 TChild = class (TParent) { descendant of TParent } 6 var {...} s : TStringList; 7 end ; { class TChild } v : TMyObject; { v can also be used as a TObject } 8 9 TChild is a subclass , or descendant , derived from TParent . 10 begin s := TStringList.Create 11 TChild inherits all fields and methods from TParent . 12 ; v := TMyObject.Create 13 ; s.AddObject(’Tom’, v) { TMyObject substituted for TObject } TChild can have additional fields and methods. � 2007, T. Verhoe ff @ TUE.NL c 9 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 10 Program Realization 2: Lecture 4 Check Class Type of Object; Safe Cast to Derived Class Inheritance of Methods ≡ object v is an instance of (a descendent of) class T v is T 1 type v as T = object v treated as an instance of class T TParent = class (TObject) 2 procedure M; // pre: P0; post: Q0 3 1 type end ; { class TParent } TMyObject = class (TObject) 4 2 5 public 3 TChild = class (TParent) procedure M; { method that does not exist in TObject } 6 4 { ... no procedure M here ... } end ; { class TMyObject } 7 5 end ; { class TChild } 8 6 7 var 9 v : TObject; 10 var 8 v : TChild; { v also is a TParent } 11 9 10 begin 12 { somehow create v } (* v.M gives COMPILER ERROR *) 13 begin 11 12 ; if v is TMyObject then v := TChild.Create 14 with v as TMyObject do M 15 ; v.M // calls M defined in TParent 13 � 2007, T. Verhoe ff @ TUE.NL c 11 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 12 Program Realization 2: Lecture 4
Static and Virtual Method Binding Overriding Method Definitions 1 type TParent = class (TObject) 2 procedure M; virtual ; // pre: P0; post: Q0 3 end ; { class TParent } 4 • Static (default): invoke method in type of variable’s declaration . 5 TChild = class (TParent) 6 Determined at compile time . procedure M; override ; // pre: P1; post: Q1 7 end ; { class TChild } // P0 => P1, Q1 => Q0 8 9 • Virtual : invoke method in type of variable’s actual value . 10 var Determined at run time . v : TParent; 11 12 13 begin v := TChild.Create 14 15 ; v.M // calls M defined in TChild � 2007, T. Verhoe ff @ TUE.NL c 13 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 14 Program Realization 2: Lecture 4 Abstract Methods Abstract Classes 1 type TParent = class (TObject) { abstract class } 2 procedure M; virtual ; abstract ; // pre: P0; post: Q0 3 An abstract method is a placeholder for a contract. end ; { class TParent } 4 5 TChild = class (TParent) { concrete descendent } It does not have an implementation. 6 procedure M; override ; // pre: P1; post: Q1 7 end ; { class TChild } // P0 => P1, Q1 => Q0 8 It cannot be called. 9 10 (* procedure TParent.M cannot be implemented *) It must be implemented in a derived class. 11 12 procedure TChild.M; { implementation of M in derived class } begin {...} end ; 13 � 2007, T. Verhoe ff @ TUE.NL c 15 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 16 Program Realization 2: Lecture 4
ADTs with Multiple Implementations Abstract TRectangle with two implementations programs-lecture-4.zip contains • The contract is defined in a separate class without private fields and with virtual, abstract methods . • abstractrectanglesexample/rectangles.pas Derived queries can already be implemented as virtual methods in terms of basic queries. • abstractrectanglesexample/rectanglestest.pas This is called an abstract base class . • methodbindingexample/methodbindingexample.pas • Each implementation inherits from the abstract base class, and provides a data representation in protected or private fields and 1 unit Rectangles; implementations for all abstract methods using override . { provides ADT for axis-parallel grid rectangles 2 with abstract base class and two implementations } 3 � 2007, T. Verhoe ff @ TUE.NL c 17 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 18 Program Realization 2: Lecture 4 Using TRectangle with two implementations Visibility attributes of class members 1 program RectanglesTest; 2 3 uses Rectangles; 4 • private : access restricted to the same unit 5 6 var r, s: TRectangle; 7 • protected : like private but also accessible in any derived class 8 9 begin • public : accessible anywhere r := TRectangleLowHigh.Create(0, 0, 200, 100) 10 11 ; s := TRectangleLowDim.Create(100, 50, 300, 150) 12 ; r.Intersect(s) 13 ; if r.Contains(50, 50) then writeln(’Huh?’) 14 end . � 2007, T. Verhoe ff @ TUE.NL c 19 Program Realization 2: Lecture 4 � 2007, T. Verhoe ff @ TUE.NL c 20 Program Realization 2: Lecture 4
Recommend
More recommend
