K. Stirewalt CSE 335: Software Design 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]

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design 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; };

K. Stirewalt CSE 335: Software Design 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!

K. Stirewalt CSE 335: Software Design 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) {} };

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design Exercise Draw a UML class diagram that illustrates the composite nature of the Expr class hierarchy.

K. Stirewalt CSE 335: Software Design First attempt at model of the Expr class hierarchy Expr BinaryExpr AddDivideMultiply Subtract Variable name : string Literal val : double UnaryExpr Negate child left right * * *

K. Stirewalt CSE 335: Software Design First attempt at model of the Expr class hierarchy Expr BinaryExpr AddDivideMultiply Subtract Variable name : string Literal val : double UnaryExpr Negate child left right * * * Question: Can you spot any problems with this model?

K. Stirewalt CSE 335: Software Design Consider the following object models : Add : Literal val = 5.0 : Add : Subtract left right left

K. Stirewalt CSE 335: Software Design DocumentParagraphSentence 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

K. Stirewalt CSE 335: Software Design 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 C aggAB aggBC

K. Stirewalt CSE 335: Software Design Car Engine Deep hierarchies: Part-explosion diagrams GearboxBodyWheel DoorHoodTrunk 1..* 4

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design Better model of the Expr hierarchy Expr BinaryExpr AddDivideMultiply Subtract Variable name : string Literal val : double UnaryExpr Negate child left right * * *

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design Examples of Aggregations Vehicle VehiclePart 1..* Polygon LineSegment Vehicle comprises the parts; Parts may be “parts of” vehicles Where assembly appears, its parts also appear. Destroying the assembly means deleting its parts 3..* 0..1 *

K. Stirewalt CSE 335: Software Design Example with both compositions and associations CompanyDivisionDepartment Person employs * * **

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design 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);

K. Stirewalt CSE 335: Software Design Composite pattern (idealized) ClientComponent Operation() Composite Operation() Add(Component) Remove(Component) GetChild(int) : Component Leaf Operation() children * *

K. Stirewalt CSE 335: Software Design Composite pattern (most general) ClientComponent Operation() Add(Component) Remove(Component) GetChild(int) : Component Composite Operation() Add(Component) Remove(Component) GetChild(int) : Component Leaf Operation() children * *

K. Stirewalt CSE 335: Software Design 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

K. Stirewalt CSE 335: Software Design Question Can you come up with another example use of the Composite pattern?