Presentation is loading. Please wait.

Presentation is loading. Please wait.

OOD and Inheritance (Chapter 5 in text). Designing With Inheritance  Inheritance: the ability to define new classes as refinements or extensions of previous.

Similar presentations

Presentation on theme: "OOD and Inheritance (Chapter 5 in text). Designing With Inheritance  Inheritance: the ability to define new classes as refinements or extensions of previous."— Presentation transcript:

1 OOD and Inheritance (Chapter 5 in text)

2 Designing With Inheritance  Inheritance: the ability to define new classes as refinements or extensions of previous ones  Inheritance is a central feature of OOD and OOP because: 1. Simplifies programming 2. Allows code to be reused through sharing 3. Can refine and extend code through virtual methods.

3 Example: Stacks and Queues Front Rear Items enter here Items exit here Top Items both enter and exit here

4 Stack as a Variation of Queue Front Rear Items enter here Items exit here Front Items enter here Items exit here

5 New Terminology  Conceived this way, stacks and queues differ only in where items enter  So we will call an ordinary queue a rear queue since items enter at rear  First-in, First-out (FIFO)  We will call a stack a front queue since items enter front  Last-in, First-out (LIFO)

6 Generalization Class Diagram We will say that front queues and rear queues are extensions (derived subclasses) of a general queue class: Queue FrontQueueRearQueue

7 Attributes (Data) in Common  What attributes do stacks (front queues) and queues (rear queues) have in common?  An underlying structure (for example, an array)  A place where items are added (for example, an index)  A place from which items are removed

8 Operations in Common  What operations do stacks and queues have in common (regardless of how the operations are implemented)?  Create  Add an item  Remove an item  Check for emptiness  Check for fullness  Display

9 Generalization Diagram Again Queue maxSize: Integer front: Integer rear: Integer display(): void add(Item): void remove(): Item empty(): Boolean full(): Boolean FrontQueueRearQueue Item * items 1

10 Abstract Classes  The Queue class is conceived to be what is common to both the FrontQueue and RearQueue classes  It makes no sense to make an object of type Queue ; it is abstract (name in italics)  Operations in italics are abstract, like place holders; they must be overridden by the extending classes FrontQueue and RearQueue  The FrontQueue and RearQueue classes inherit data attributes from Queue

11 Polymorphism Polymorphism is the ability of a language to determine which operation to use among many of the same name. Simple examples performed statically at compile time: - type conversion - operator overloading - function overloading by parameter and return types Pure polymorphism is the ability to choose among operations of the same name dynamically at run time. In C++, pure polymorphism is achieved through inheritance and virtual functions.

12 An Abstract QueueInfo Class in C++ class QueueInfo { protected: ItemArray items; Integer maxSize; Integer front; Integer rear; public: QueueInfo(Integer size); ~QueueInfo(); void add(ItemArray newItems, Integer numItems); virtual void display(); virtual void add(Item item) =0 ; virtual Item remove() =0 ; virtual Boolean empty() =0 ; virtual Boolean full() =0 ; };

13 Notes on the QueueInfo Class  The protected keyword has the same meaning as private, except that protected data is accessible to class extensions (subclasses)  The virtual keyword on a method without the =0 body means the method may be overridden by subclasses  The virtual keyword on a method with the =0 body means the method must be overridden by subclasses (pure virtual method)

14 Notes on the QueueInfo Class (cont'd)  The QueueInfo constructor is not virtual, and will be shared by RearQueueInfo and FrontQueueInfo objects  Must be implemented by QueueInfo class  The add method is overloaded:  The non-virtual version will be shared and must be implemented by QueueInfo class  The virtual version must have separate definitions in both RearQueueInfo and FrontQueueInfo classes

15 The Difference Between Overloading and Overriding  Suppose q is of type FrontQueue. Consider:  q->add(itemArray, numItems);  q->add(item);  The difference between these two calls can be determined by the compiler on the basis of the calls' signatures  This is an example of method overloading  Also called ad-hoc polymorphism

16 The Difference Between Overloading and Overriding (cont'd)  Suppose q is of declared type Queue. Consider:  q->add(item);  Since the one-parameter add method is only defined for FrontQueue s and RearQueue s, which method does this refer to?  Answer: can only be determined at run-time by looking at the specific type for q  This is an example of method overriding  Also called pure polymorphism

17 Pure Polymorphism Example class CommandInterpreterInfo { private: Queue q; // either a RearQueue or FrontQueue Character cmd; // queue command: c, a, r, or d Character qtype; // queue type: r or f Integer qsize; // queue size... public: CommandInterpreterInfo(); void execute(); // run this command interpreter private:... void processCreate(); // process a cr or cf command void checkEOF(); // check for premature EOF... };

18 Pure Polymorphism Example (cont'd) void CommandInterpreterInfo::processCreate() { if (cmd != 'c') { } cin >> qtype; checkEOF(); if ( (qtype == 'f') || (qtype == 'r') || (qtype == 'p') ) { cin >> qsize; checkEOF(); switch ( qtype ) { case 'f': q = new FrontQueueInfo(qsize); cout << "Front"; break; case 'r': q = new RearQueueInfo(qsize+1); cout << "Rear"; break; case 'p':... } cout << " Queue Created of Size " << qsize << endl; } else { } }

19 QueueInfo Constructor  QueueInfo objects are not explicitly constructed using new  However, a QueueInfo constructor can be defined as what is common between FrontQueueInfo and RearQueueInfo: QueueInfo::QueueInfo(Integer size) { maxSize = size; items = new Item[maxSize]; for (Integer i = 0; i < maxSize; i++) { items[i] = NULL; }

20 Defining Subclasses in C++: Example class FrontQueueInfo : public QueueInfo { public: FrontQueueInfo(Integer n); void add(Item item); Item remove(); Boolean empty(); Boolean full(); void display(); }; Similarly for RearQueueInfo

21 Notes on the Example  The `` : public QueueInfo '' construction means that FrontQueueInfo is to inherit all public and protected methods from QueueInfo  FrontQueueInfo has its own constructor to supplement that ``inherited'' from QueueInfo  FrontQueueInfo has a display method, even though it doesn't have to

22 Subclass Constructors Constructors for subclasses indicate in their headers which parent class constructor to use: FrontQueueInfo::FrontQueueInfo(Integer n): QueueInfo(n) { } RearQueueInfo::RearQueueInfo(Integer n): QueueInfo(n) { }

23 Non-Pure Virtual Methods  The display method in the QueueInfo class is virtual, but not pure  Thus, it has a definition in the QueueInfo class: void QueueInfo::display() { for (Integer i = 0; i < maxSize; i++) { if ( items[i] == NULL ) cout << " ___" ; else items[i]->display(); } cout << endl; }

24 Non-Pure Virtual Methods (cont'd)  If a subclass does not override a nonpure virtual method, then its parent's definition will be used  In the display example, the parent definition simply dumps out the contents of the array  This is not how the final display is supposed to look for the assignment, but it can be used for debugging  If a subclass does override a virtual method, the method for the most specific type is used

25 Inheritance and Separate Compilation When a subclass and its parent class are in separate modules, the subclass module must be remade whenever the parent class module is. Makefile: RearQueueInfo.o: QueueInfo.o g++ -c -o RearQueueInfo.o Failure to do this can cause bizarre behavior.

26 Inheritance Pitfalls (;-) Mutant Marsupials Take Up Arms Against Australian Air Force As virtual reality simulators assume larger roles in helicopter combat training, programmers have gone to great lengths to increase the realism of their scenarios, including detailed landscapes and - in the case of the Northern Territory's Operation Phoenix- herds of kangaroos (since disturbed animals might well give away a helicopter's position). The head of the Defense Science & Technology Organization's Land Operations/Simulation division reportedly instructed developers to model the local marsupials' movements and reactions to helicopters.

27 Inheritance Pitfalls (cont'd) Being efficient programmers, they just re-appropriated some code originally used to model infantry detachment reactions under the same stimuli, changed the mapped icon from a soldier to a kangaroo, and increased the figures' speed of movement. EnemyInfantry position type speed armament... Kangaroo

28 Inheritance Pitfalls (cont'd) Eager to demonstrate their flying skills for some visiting American pilots, the hotshot Aussies "buzzed" the virtual kangaroos in low flight during a simulation. The kangaroos scattered, as predicted, and the visiting Americans nodded appreciatively... then did a double-take as the kangaroos reappeared from behind a hill and launched a barrage of Stinger missiles at the hapless helicopter. Easy remedy: Make the armament attribute privat e and specify publi c inheritance.

29 A Better Design DesertObject position type speed... Kangaroo EnemyInfantry armament

30 Inheritance Hierarchy Example: Symbolic Differentiation Symbolic differentiation (taking the derivative of an expression) can be accomplished with expressions trees. E.g., the derivative of x*(x+4)-5 = 2x+4 - * + 5 X X 4 An expression tree for x*(x+4)-5

31 Rules for Symbolic Differentiation d(A-B) = d(A) - d(B) d(A+B) = d(A) + d(B) d(A*B) = A*d(B) + d(A)*B d(Constant) = 0 d(x) = 1

32 Transforming the Expression Tree - * + 5 X X 4 - + * 0 * X + 0 1 + 1 0 X 4 4 Apply derivation rules

33 Rules for Arithmetic Simplification A - 0 ⇒ A A + 0 ⇒ A A * 1 ⇒ A 1 * A ⇒ A

34 Simplifying the Expression Tree - + * 0 * X + 0 1 + 10 X 4 + X + X 4 Apply simplification rules

35 Basic Data Flow Expression Trees Differentiate Simplify However, there needs to be a way to convert textual expressions to expressions trees, and vice versa.

36 Parsing Parsing is the process of converting input expressions into expression trees. It first must recognize the individual components: operators, variables, and constants (called tokens): Equations Tokenizer Tokens Expression Treee Builder Expression Trees Parser

37 Total Data Flow Expression Trees Differentiate Simplify Parser Unparser Equations O Output

38 Potential Data Classes  Input Stream  Token  Token Stream  Expression Tree  Expression Tree Node  Output Stream

39 Potential Algorithm Classes  Main  Parser  Differentiator  Simplifier  Unparser

40 Expression Tree Class An expression tree suggests a natural hierarchy among expression tree nodes: Node Operator Node Leaf Node Binary Operator Unary Operator Constant Variable MinusAddSubMultDivExp An "is-a" hierarchy

41 Inheritance and "Is-a" Hierarchies  Is-a hierarchies should be implemented through inheritance because:  Common properties can be factored out and defined only once (e.g. Printing)  New items can be added with minimal effort  Rest of program can be written to operate on a generic type Expr and ignore details of actual expressions  The program documents itself by being organized to mirror real-world objects

42 Deep vs. Shallow Hierarchies A deep hierarchy: A shallow hierarchy: A deep hierarchy yields more opportunity for reuse, but it may be difficult to follow code. A shallow hierarchy indicates objects do not have much commonality. A good design will balance depth and breadth.

Download ppt "OOD and Inheritance (Chapter 5 in text). Designing With Inheritance  Inheritance: the ability to define new classes as refinements or extensions of previous."

Similar presentations

Ads by Google