The Composite Design Pattern – Materials – Announcements

View Github Repository Open presentation in a new window

mattlockyer

See all presentation from mattlockyer

The Composite Design Pattern – Materials – Announcements

0 0

composite-pattern

Composite Pattern Lecture for my Interview with UBC

On Github mattlockyer / composite-pattern

The Composite Design Pattern

  • Announcements
  • Recap: Design Patterns
  • Overview
  • Design: Component, Leaf, Composite
  • The Problem
  • Motivation
  • Challenge: UML and Implementation
  • Discussion

Materials

Announcements

  • Midterm Grades Posted on Canvas
  • Quiz Next Thursday

Recap: Design Patterns

  • General Solution to Common Problem
  • Template vs. Implementation
  • UML: Relationships and Interactions

Overview: Composite Pattern

"Compose objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly." Design Patterns - Elements of Reusable Object-Oriented Software

Tree Structures?

Part-Whole Hierarchies?

We'll get back to these in a moment...

Design

Component

  • Abstraction for all components
  • Declares interface for objects in the pattern

Leaf

  • Implements ALL Component class methods
  • Primitive component with NO children

Composite

  • Implements ALL Component class methods - generally accomplished through delegation to children
  • Has a collection of children
  • Implements methods to manipulate children

Problem

Having distinct interfaces for every leaf and composite leads to unnecessary complexity in our applications.

The pattern addresses a "high fan out" problem where one interface needs to be aware of several other interfaces.

This usually results in run-time type checking (BAD) and other code smells.

Why Bother?

Recursive Data Structures (ex: Files and Folders) are examples of composite objects created from primitive leaf components and other composites.

If our user treats these objects as the same... (open, read, write) then so can our application code, and...

These objects can likely implement the same interface!

Advantages

A successful implementation results in "1-1" or "many to 1" relationships with the Component class interface.

Application code can call a method of a component, for example: "print" or "copy" without worrying whether the type is leaf or composite.

Example: Text Editor

Objects: word, sentence

A sentence is simply a composite of words and each word object has a local position inside the sentence.

We can copy, move, delete or display the whole sentence with one method call in our application code, and the sentence object will delegate these method calls to it's children, the word objects.

But wait! What about paragraphs...?

Example: GUI

Example: Graphics

Implementation Quiz

Use an abstract class to represent leaf AND composite objects. Store a collection of leaf objects in the composite class. Define functionality in the composite class to manage the collection of leaf objects.

Challenge

Design and implement a graphics engine to render ellipses, rectangles and graphics (composite group of either ellipses or rectangles).

Requirements

Application code should be able to do the following:

  • create objects of type: Ellipse, Rectangle and Graphic
  • add and remove objects from a Graphic instance
  • draw objects from any type

UML Design Challenge

abstract class

Requirements

  • create Ellipse
  • create Rectangle
  • create Graphic
  • add/remove from Graphic
  • draw object
  • draw Graphic object

Design - Discussion

Implementation

Using our design, we will write a few lines of code to implement it.

Again we will extend the abstract class Component.

Solution Walkthrough

Success

Congratulations you implemented the Composite Pattern!

Tree Structures and Part Whole Hierarchies

Remember these terms?

Well our graphics example defines a tree structure though composition, this is also sometimes referred to as a "scene graph" in graphics engines.

The composition structure also defines a hierarchy of parts in the context of the composite whole.

Finer Points

Parent References

Where should we define parent references (if any)?

Transparency vs. Security

Where do we define our methods for manipulating children?

Remember the graphics example from earlier?

Questions

Thank You

The Composite Design Pattern Announcements Recap: Design Patterns Overview Design: Component, Leaf, Composite The Problem Motivation Challenge: UML and Implementation Discussion