Irvine COP 4814

COP 4814 Florida International University

Kip Irvine

Introduction to Design Patterns

based on: Head-First Design Patterns,

Chapter 1

Updated: 3/21/2016

Overview

• Why use design patterns? • What are design patterns? • Three general types of patterns • Introducing UML diagrams • Introducing the Strategy Pattern • Ducks example from Chapter 1

Irvine COP 4814

Why use design patterns?

• Design patterns help create software solutions that are simple, reusable and maintainable.

• Design patterns help us to describe communication between objects – avoid becoming entangled in each others' data

models and methods • Introduced in the early 1990's by Erich Gamma

– described patterns in a GUI application framework

What are Design Patterns?

• In everyday life, we say that something "is just like" another more familiar thing, with some variations.

• …recurring solutions to design problems you see over and over.

• ..identify and specify abstractions that are above the level of single classes and instances, or of components.

• ..not just about the design of objects—they are about the interactions between objects.

Three General Types

• Creational patterns -- patterns that create objects – e.g. factory, decorator, singleton

• Structural patterns -- compose groups of objects into larger structures – e.g. model-view-controller

• Behavioral patterns -- help to define the communication between objects in a system – e.g. strategy, observer

UML Diagrams

• Unified Modeling Language – a standard in the industry for describing classes, interfaces, and their relationships

• Class name, attributes, operations

Source: UML Basics – Class Diagrams, from IBM DeveloperWorks

Operations

Format for describing an operation

name(parameter list) : type of value returned

Examples: calculate(double hours, double rate) : double

isValid( ) : boolean

getName( ) : string

Visibility of Members + indicates a public member

# indicates a protected member (visible to subclasses only)

− indicates a private member

~ indicates a member with package-level visibility

Inheritance Relationships

Class name in italics is an abstract class

Bidirectional Association

Two classes that are both aware of each other and can call each others' methods have a bidirectional association (solid line).

Uni-Directional Association

Two classes are related, but only one of the classes know that the relationship exists.

Basic Aggregation

A type of association:

One class is part of another class. For example, a Car may contain Wheel objects, an Engine object, and many others. The child class instance can outlive its parent class instance. In the example below, a Wheel can exist even when no Car exists.

Composition Aggregation

Another type of association:

Another type of aggregation in which the child class instance's lifecycle is dependent on the parent child's lifecycle. In this example, the Department instance cannot exist independently of the Company instance.

Interfaces An interface describes a common set of operations for all classes that implement the interface. When a class implements an interface, it agrees to provide concrete versions of all the interface methods.

Below, the Professor and Student classes implement the Person interface.

Strategy Pattern

• Components often contain classes that embody behaviors – buying and selling stocks – aircraft simulation – browser plugins – data encryption – managing network flow

• Should their code be hard-wired into an application? – what if a behavior must be modified at runtime?

Irvine COP 4814

Strategy Pattern

• Rather than hard-wiring behaviors into classes when designing them, why not make them more flexible?

• Think of categories of behaviors – then create types that implement these categories – You can swap out one behavior for another, as long

as their behavior category is the same

Irvine COP 4814

Ducks Example (book)

Imagine an abstract Duck class with two categories of behaviors:

abstract class Duck {

FlyBehavior howToFly;

QuackBehavior howToQuack;

}

Irvine COP 4814

Ducks Example (book)

Define two behavior categories:

interface FlyBehavior {

void fly();

}

interface QuackBehavior {

void quack();

}

Irvine COP 4814

Ducks Example (book)

Create classes that implement the behavior categories:

class FlyWithWings implements FlyBehavior {

void fly() { print(“I can fly with wings!”); }

}

class RealQuackSound implements QuackBehavior {

void quack() { print(“Real quacking sound”); }

}

Irvine COP 4814

Ducks Example (book)

Define a specific type of duck and assign behaviors:

class MallardDuck extends Duck {

MallardDuck() {

howToFly = new FlyWithWings();

howToQuack = new RealQuackSound();

}

}

Irvine COP 4814

Ducks Example (book)

Define another type of duck:

class ModelDuck extends Duck {

ModelDuck() {

howToFly = new FlyNoWay();

howToQuack = new SilentQuack();

}

}

Irvine COP 4814

Ducks Example (book)

What if you could change a duck’s behavior at runtime?

abstract class Duck {

FlyBehavior howToFly;

QuackBehavior howToQuack;

void setFlyBehavior( FlyBehavior howToFly ) {

this.howToFly = howToFly;

}

}

Irvine COP 4814

Ducks Example (book)

Now the test program can make the behavior dynamic: class DuckSimulator { public static void main(...) { Duck dd = new ModelDuck(); dd.fly(); // “I cannot fly” dd.setFlyBehavior( new RocketPowered() ); dd.fly(); // “I am flying with a rocket!” } }

Irvine COP 4814