1 / 42

Object-Oriented Design and Inheritance The Big Picture

Object-Oriented Design and Inheritance The Big Picture. 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: Simplifies programming

sutton
Télécharger la présentation

Object-Oriented Design and Inheritance The Big Picture

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Object-Oriented Design and InheritanceThe Big Picture

  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: • Simplifies programming • Allows code to be reused through sharing • Can refine and extend code through virtual methods.

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

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

  5. Data Structures 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 FrontQueue RearQueue

  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 or linked list) • 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 Item 1 maxSize: Integer front: Integer rear: Integer * items display(): void add(Item): void remove(): Item empty(): Boolean full(): Boolean FrontQueue RearQueue

  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 FrontQueues and RearQueues, 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') { <error: first command must be create> } 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 { <error: bad queue type> } }

  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 forRearQueueInfo

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

  22. Subclass Constructors Constructors for subclasses indicate in their headers which parent class constructor to use: FrontQueueInfo::FrontQueueInfo(Integer n): QueueInfo(n) { < code to initialize a new front queue > } RearQueueInfo::RearQueueInfo(Integer n): QueueInfo(n) { < code to initialize a new rear queue > }

  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 RearQueueInfo.cc ... <TAB>g++ -c RearQueueInfo.cc -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 private and specify public inheritance.

  29. A Better Design DesertObject position type speed . . . EnemyInfantry Kangaroo 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 An expression tree for x*(x+4)-5 + X X 4

  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 - - Apply derivation rules + * 0 0 5 * * + X + 1 + X X 4 4 X 1 0 4

  33. Simplifying the Expression Tree - + Apply simplification rules + 0 0 X * * + + 1 + X X 4 X 1 0 4

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

  35. 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): Tokens Tokenizer Equations Parser Expression Treee Builder Expression Trees

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

  37. Potential Data Classes • Input Stream • Token • Token Stream • Expression Tree • Expression Tree Node • Output Stream

  38. Potential Algorithm Classes • Main • Parser • Differentiator • Simplifier • Unparser

  39. Expression Tree Class An expression tree suggests a natural hierarchy among expression tree nodes: An "is-a" hierarchy Node Operator Node Leaf Node Unary Operator Variable Binary Operator Constant Minus Add Sub Mult Div Exp

  40. 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

  41. 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.

  42. Some things to consider in terms of OOD and InheritanceEnd of Lecture

More Related