object oriented design and inheritance the big picture n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Object-Oriented Design and Inheritance The Big Picture PowerPoint Presentation
Download Presentation
Object-Oriented Design and Inheritance The Big Picture

Loading in 2 Seconds...

play fullscreen
1 / 42

Object-Oriented Design and Inheritance The Big Picture - PowerPoint PPT Presentation


  • 114 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Object-Oriented Design and Inheritance The Big Picture' - sutton


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
designing with inheritance
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.
example stacks and queues
Example: Stacks and Queues

Rear

Front

Items enter

here

Items exit

here

Items both enter

and exit here

Top

stack as a variation of queue
Stack as a Variation of Queue

Rear

Front

Items enter

here

Items exit

here

Items exit

here

Front

Items enter

here

data structures terminology
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)
generalization class diagram
Generalization Class Diagram

We will say that front queues and rear queues

are extensions (derived subclasses) of a general

queue class:

Queue

FrontQueue

RearQueue

attributes data in common
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
operations in common
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
generalization diagram again
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

abstract classes
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
polymorphism
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.

an abstract queueinfo class in c
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 ;

};

notes on the queueinfo class
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)
notes on the queueinfo class cont d
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
the difference between overloading and overriding
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
the difference between overloading and overriding cont d
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
pure polymorphism example
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

. . .

};

pure polymorphism example cont d
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> }

}

queueinfo constructor
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;

}

}

defining subclasses in c example
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

notes on the example
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.
subclass constructors
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 >

}

non pure virtual methods
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;

}

non pure virtual methods cont d
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
inheritance and separate compilation
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.

inheritance pitfalls
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.

inheritance pitfalls cont d
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

inheritance pitfalls cont d1
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.

a better design
A Better Design

DesertObject

position

type

speed

. . .

EnemyInfantry

Kangaroo

armament

inheritance hierarchy example symbolic differentiation
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

rules for symbolic differentiation
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

transforming the expression tree
Transforming the Expression Tree

-

-

Apply derivation

rules

+

*

0

0

5

*

*

+

X

+

1

+

X

X

4

4

X

1

0

4

simplifying the expression tree
Simplifying the Expression Tree

-

+

Apply simplification

rules

+

0

0

X

*

*

+

+

1

+

X

X

4

X

1

0

4

basic data flow
Basic Data Flow

Differentiate

Expression

Trees

Simplify

However, there needs to be a way

to convert textual expressions to

expressions trees, and vice versa.

parsing
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

total data flow
Total Data Flow

Equations

Parser

Differentiate

Expression

Trees

Simplify

Unparser

Output

O

potential data classes
Potential Data Classes
  • Input Stream
  • Token
  • Token Stream
  • Expression Tree
  • Expression Tree Node
  • Output Stream
potential algorithm classes
Potential Algorithm Classes
  • Main
  • Parser
  • Differentiator
  • Simplifier
  • Unparser
expression tree class
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

inheritance and is a hierarchies
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
deep vs shallow hierarchies
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.