Synthetic OO Design Concepts & Reuse Lecture 2: Abstract classes and composite structures

CSE 335: Software Design K. Stirewalt

Synthetic OO Design Concepts & Reuse Lecture 2: Abstract classes and composite structures

Topics:– Elaboration of the expression class hierarchy– New modeling concepts: Aggregation and composition

associations [Blaha and Rumbaugh § 4.4]– Composite object structures– The Composite pattern [Gamma]


Recall: Economics of software development

Problem: Financing development of software systems– Big software is notoriously expensive over long term– Many software projects run out of money before they ever yield

a product

What the manager can do:– Outsource development to cheaper programmers– “Buy vs. build” – Amortize costs over long term: Design for change– Create assets that have intrinsic value and that pay dividends:

Reusable libraries


Uses of abstract classes

Defining an abstract “placeholder” that can hold objects of various types– E.g., Shape– Useful for building composite object structures

Factoring common code into an abstract concept

Serving as a program fragment in the design of a family of programs

Definition of role-classes for use in collaboration-based designs


Uses of abstract classes

Defining an abstract “placeholder” that can hold objects of various types– E.g., Shape– Useful for building composite object structures

Factoring common code into an abstract concept

Serving as a program fragment in the design of a family of programs

Definition of role-classes for use in collaboration-based designs


Recall: Collaborative Exercise

Design classes for arithmetic expression trees. Each arithmetic operator class should provide operations for retrieving operand expressions. Define at least the following classes:

– Variable– Literal– Negate– Add, Subtract, Multiply, Divide

Hint: You will need to invent some abstract classes


Classes Expr and Literal

class Expr {

public:

virtual ~Expr() {}

protected:

Expr() {}

};

Note: Constructor is not public!

class Literal : public Expr {

public:

Literal( double d )

: _val(d) {}

double value() const

{ return _val; }

protected:

double _val;

};


Class BinaryExpr

class BinaryExpr : public Expr { public: const Expr* getLeftOperand() const { return leftOperand; } const Expr* getRightOperand()const { return rightOperand; }

protected: const Expr* leftOperand; const Expr* rightOperand;

BinaryExpr( const Expr* l, const Expr* r ): leftOperand( l ), rightOperand( r ) {}

};

Note: Constructor is not public!


Example: Classes Add and Multiply

class Add : public BinaryExpr { public: Add( Expr* l, Expr* r ) : BinaryExpr(l,r) {}

};

class Multiply : public BinaryExpr { public: Multiply( Expr* l, Expr* r ) : BinaryExpr(l,r) {}

};


Exercise

int main(void){ Variable* x = new Variable(“x”); Variable* y = new Variable(“y”); Literal* l1 = new Literal(5.0); Literal* l2 = new Literal(3.9);

Expr* e = new Add(l1, new Multiply(x,l2)); … Expr* e2 = new Divide(e, new Subtract(y,x)); …}

Draw a UML object diagram depicting expressions e and e2


Exercise

Draw a UML class diagram that illustrates the composite nature of the Expr class hierarchy.


First attempt at model of the Expr class hierarchy

Expr

BinaryExpr

Add Divide Multiply Subtract

Variable

name : string

Literal

val : double

UnaryExpr

Negate

child

left

right

* *

*


First attempt at model of the Expr class hierarchy

Expr

BinaryExpr


Variable

name : string

Literal

val : double

UnaryExpr

Negate

child

left

right

* *

*

Question: Can you spot any problems with this model?


Consider the following object models

: Add

: Literal

val = 5.0

: Add

: Subtract

left

right right

right

left left


Document Paragraph Sentence1..* 1..*

New concept: Aggregation

Special kind of association with additional semantics– Minimally: Transitive and anti-symmetric

A.k.a., the is-part-of or part-whole association– A sentence is part of a paragraph (a paragraph comprises sentences)– A paragraph is part of a document (a document comprises paragraphs)

Two forms:– strong aggregation (a.k.a. composition)– weak aggregation


Terminology: Parts and assemblies

Instances of classes on the “diamond end” of an aggregation are called assemblies; instances of classes on the non-diamond end are called the parts of an assembly.

E.g.:– aggAB: instances of A are the assemblies, instances of B are the parts– aggBC: instances of B are the assemblies, instances of C are the parts– Parts that are also assemblies give rise to deep aggregation

hierarchies

A B CaggAB aggBC


Car

Engine

Deep hierarchies: Part-explosion diagrams

GearboxBodyWheel

Door Hood Trunk

1..*

4


Aggregation Versus Association

Aggregation is a special kind of an association:

Use aggregation when:– association might naturally be called “is-part-of” or “is-

made-of”– some operations on the assembly object automatically

apply to the part objects• E.g., deletion, moving, recomputing, etc

– some values propagate from the assembly to all or some of the parts

– there is an intrinsic asymmetry to the association• i.e., one class is subordinate to the other


Better model of the Expr hierarchy

Expr

BinaryExpr


Variable

name : string

Literal

val : double

UnaryExpr

Negate

child

left

right

*

*

*


Aggregation vs. composition

Composition is a strong form of aggregation with additional semantic constraints:– A part can belong to at most one assembly– Once a part has been assigned to an assembly, its

lifetime is coincident with that of the assembly

Composition implies ownership of parts by assembly– Deletion of assembly object triggers deletion of

component objects


Examples of Aggregations

Vehicle VehiclePart1..*

Polygon LineSegment

Vehicle comprises the parts; Parts may be “parts of” vehicles

Where assembly appears, its parts also appear.

Destroying the assembly meansdeleting its parts

3..*0..1

*


Example with both compositions and associations

Company Division Department

Person

em

plo

ys

*

*

**


Composite object structures

Expression trees are examples of composite object structures– General notion of an expression, which may be a:

• simple object (e.g., an instance of a Variable or Literal) or• composite object (e.g., instance of an Add, Subtract,

Multiply, or Divide)

Composite structures show up frequently in real object-oriented designs

Composite designs especially useful when the abstract class declares polymorphic operations


Exercise

Extend Expr hierarchy with polymorphic operation:void print( ostream& )

It should be possible to execute code such as:Expr* l = new Literal(5.0);

Expr* v = new Variable(“x”);

Expr* e = new Add( l, v );

e->print(cout);

l->print(cout);

v->print(cout);


Composite pattern (idealized)

Client Component

Operation()

Composite

Operation()Add(Component)Remove(Component)GetChild(int) : Component

Leaf

Operation()

children*

*


Composite pattern (most general)

Client Component


Composite


Leaf

Operation()

children

*

*


Design virtues of composites

Makes client code simple– Clients treat composite structures and individual

objects uniformly– Design principle: Abstraction through use of the

abstract class Component and the identification of abstract operations that apply to many types of objects

Makes it easy to add new kinds of components without modifying any client code– Design principle: Incrementality– Design principle: Anticipation of change


Question

Can you come up with another example use of the Composite pattern?

Documents

Synthetic OO Design Concepts & Reuse Lecture 2: Abstract classes and composite structures