CISC 323 Intro to Software Engineering Topic 6: Design Patterns - - PowerPoint PPT Presentation

CISC 323 Intro to Software Engineering

Topic 6: Design Patterns

Readings in Custom Courseware, taken from Design Patterns: Elements of Reusable Object-Oriented Software by Gamma, Helm, Johnson, Vlissides ("Gang Of Four")

CISC 323, Winter 2003, Design Patterns 2

What Is a Design Pattern?

"an important and recurring design in object-oriented systems" "names, abstracts and identifies the key aspects of a common design structure"

• classes & objects
• role of each
• how they collaborate

like patterns in writing:

• "Tragically Flawed Hero", "Romantic Novel"
• r patterns in music: fugue, rondo, sonata

sometimes called "micro-architectures"

CISC 323, Winter 2003, Design Patterns 3

What Is a Design Pattern?

a set of rules of how to structure code in order to solve a particular class of problem way to pass on "tricks" of experienced designers Provides vocabulary to discuss design "toolbox" for OO designers; not always have to design from scratch Particularly suited to OO design as patterns can be expressed in terms of classes, associations

CISC 323, Winter 2003, Design Patterns 4

A Design Pattern Is Not....

....an idea invented by ivory-tower academics. All are "mined" from real applications and experience ....a blueprint for a whole program. Generally solves a small problem, part of a larger program. Program may use several design patterns. ....actual code. Common pattern of interaction between classes & objects, programmer fills in details for specific project. ....domain-specific. General patterns that may be useful in many areas.

CISC 323, Winter 2003, Design Patterns 5

Quality Attributes

Requirements analysis determines desired quality attributes

• f system

When designing system, attempt to

• Identify areas of risk where quality attributes may not be

met

• Reduce risk through design choices

Some attributes amenable to mathematical expression (performance, availability), others less so (modifiability)

CISC 323, Winter 2003, Design Patterns 6

Examples of Quality Attributes

Performance Availability Security Modifiability Usability Testability

CISC 323, Winter 2003, Design Patterns 7

Quality Attribute Trade-Offs

To improve one quality attribute, may have to accept a loss in another Examples:

• increase performance by using very complex algorithm:

loss in modifiability

• increase availability by replicating data: reduces security

Therefore, design choices rely on knowing required targets for quality attributes Design patterns normally help in improving at least one quality attribute, perhaps at the expense of others

CISC 323, Winter 2003, Design Patterns 8

Different Types of Design Patterns

creational: creation of objects

• Builder

structural: how classes and objects are put together to form larger structures

• Adapter
• Composite
• Facade

behavioral: algorithms & communication between objects

• Iterator
• Visitor

CISC 323, Winter 2003, Design Patterns 9

Pattern #1: Adapter

actually 2 related patterns:

• object adapter
• class adapter

2 ways to solve the same kind of problem, each with advantages and disadvantages

CISC 323, Winter 2003, Design Patterns 10

Adapters: The Situation

You have a class to implement, methods prescribed for you In Java terms, you need to implement a given interface You find an existing class which provides the functionality you need, but with a different interface You'd like to use that existing class instead of having to start from scratch

CISC 323, Winter 2003, Design Patterns 11

Example: Task Queue

You need a class to represent a queue of tasks to be done Reminder: queue is a list of elements, only operations are:

• add to one end (enqueue)
• remove from other end (dequeue)
• query if queue is empty

"FIFO" (first in, first out) Assumes there is an existing Task class

CISC 323, Winter 2003, Design Patterns 12

Example: Task Queue

public interface Queue { // Adds a task to back of queue. void enqueue(Task t); // Removes a task from front of queue. Task dequeue(); // True if queue is empty. boolean isEmpty(); } // end interface Queue

CISC 323, Winter 2003, Design Patterns 13

Linked List Implementation

One way to implement a queue: use a doubly-linked list of

• bjects.

A B C D

back front

Designate one end of the list as the front of the queue

CISC 323, Winter 2003, Design Patterns 14

Linked List Implementation

One way to implement a queue: use a doubly-linked list of

• bjects.

A B C D To enqueue Z: add it to the back of the list

back front

CISC 323, Winter 2003, Design Patterns 15

Linked List Implementation

One way to implement a queue: use a doubly-linked list of

• bjects.

A B C D To enqueue Z: add it to the back of the list Z

back front

CISC 323, Winter 2003, Design Patterns 16

Linked List Implementation

One way to implement a queue: use a doubly-linked list of

• bjects.

A B C D To dequeue: remove element from front of the list Z

back front

CISC 323, Winter 2003, Design Patterns 17

Linked List Implementation

One way to implement a queue: use a doubly-linked list of

• bjects.

A B C To dequeue: remove element from front of the list (result is D) Z

back front

CISC 323, Winter 2003, Design Patterns 18

Using Existing Class

Could implement the nodes & links from scratch Easier: Java API has LinkedList class: doubly-linked list of Objects All the functionality we need, but not the right interface. some methods from LinkedList:

void add(int index, Object o) void addFirst(Object o) void addLast(object o) Object remove(int index); Object removeFirst(); Object removeLast();

... many more

CISC 323, Winter 2003, Design Patterns 19

Bad Option: Ignore Interface

You could make user use LinkedList directly (two ways):

// create an empty queue LinkedList myQ = new LinkedList(); // enqueue two tasks myQ.addLast(task1); myQ.addLast(task2); // dequeue a task Task t = (Task) myQ.removeFirst(); // create an empty queue myQ = new LinkedList(); // enqueue two tasks myQ.addFirst(task1); myQ.addFirst(task2); // dequeue a task t = (Task) myQ.removeLast();

first element of list is front of queue first element of list is back of queue

CISC 323, Winter 2003, Design Patterns 20

Problems With This Option

There may be code that depends on the queue interface (enqueue, dequeue) Awkward for user: must remember what class to use, whether to add and remove from front or back of list Every user has to "translate" from queue language to linked list language: use different method names, cast to Task when doing a dequeue

CISC 323, Winter 2003, Design Patterns 21

Object Adapter For a Queue

Sometimes called a "wrapper" – we're wrapping another

• bject around a linked list to provide a different interface.

client +enqueue() +dequeue() +isEmpty() <<interface> Queue uses +enqueue() +dequeue() +isEmpty() OAQueue +addFirst() +addLast() +removeFirst() +removeLast() +isEmpty() LinkedList 1 1

CISC 323, Winter 2003, Design Patterns 22

Object Adapter Code

public class OAQueue implements Queue { // first list element is front of queue private LinkedList theList = new LinkedList();

CISC 323, Winter 2003, Design Patterns 23

Object Adapter Code

public class OAQueue implements Queue { // first list element is front of queue private LinkedList theList = new LinkedList(); // Adds a task to back of queue. public void enqueue(Task t) { theList.addLast(t); } // end enqueue

CISC 323, Winter 2003, Design Patterns 24

Object Adapter Code

public class OAQueue implements Queue { // first list element is front of queue private LinkedList theList = new LinkedList(); // Adds a task to back of queue. public void enqueue(Task t) { theList.addLast(t); } // end enqueue // Removes task from front of queue. public Task dequeue() { return (Task) theList.removeFirst(); } // end dequeue

CISC 323, Winter 2003, Design Patterns 25

Object Adapter Code

public class OAQueue implements Queue { // first list element is front of queue private LinkedList theList = new LinkedList(); // Adds a task to back of queue. public void enqueue(Task t) { theList.addLast(t); } // end enqueue // Removes task from front of queue. public Task dequeue() { return (Task) theList.removeFirst(); } // end dequeue // True if queue is empty. public boolean isEmpty() { return theList.isEmpty(); } // end isEmpty } // end class OAQueue

CISC 323, Winter 2003, Design Patterns 26

General Form of Object Adapter

1

CISC 323, Winter 2003, Design Patterns 27

Class Adapter For a Queue

Not multiple inheritance in Java: CAQueue extends a class and implements an interface.

client +enqueue() +dequeue() +isEmpty() <<interface> Queue uses +enqueue() +dequeue() CAQueue +addFirst() +addLast() +removeFirst() +removeLast() +isEmpty() LinkedList

CISC 323, Winter 2003, Design Patterns 28

Class Adapter Code

public class CAQueue extends LinkedList implements Queue { // A CAQueue is also a LinkedList // First element = front of queue

CISC 323, Winter 2003, Design Patterns 29

Class Adapter Code

public class CAQueue extends LinkedList implements Queue { // A CAQueue is also a LinkedList // First element = front of queue // Adds a task to back of the queue. public void enqueue(Task t) { addLast(t); } // end enqueue

CISC 323, Winter 2003, Design Patterns 30

Class Adapter Code

public class CAQueue extends LinkedList implements Queue { // A CAQueue is also a LinkedList // First element = front of queue // Adds a task to back of the queue. public void enqueue(Task t) { addLast(t); } // end enqueue // Removes task from front of queue. public Task dequeue() { return (Task) removeFirst(); } // end dequeue

CISC 323, Winter 2003, Design Patterns 31

Class Adapter Code

public class CAQueue extends LinkedList implements Queue { // A CAQueue is also a LinkedList // First element = front of queue // Adds a task to back of the queue. public void enqueue(Task t) { addLast(t); } // end enqueue // Removes task from front of queue. public Task dequeue() { return (Task) removeFirst(); } // end dequeue // No need to write an isEmpty method } // end class CAQueue

CISC 323, Winter 2003, Design Patterns 32

General Form of Class Adapter

CISC 323, Winter 2003, Design Patterns 33

Comparing the Two Kinds of Adapters

Object Adapter:

• Puts an object of the adaptee (i.e. LinkedList) inside each
• bject of the adaptor (i.e. OAQueue)
• Sometimes called a "wrapper"

Class Adapter:

• Adaptor is derived from the adaptee
• Uses class extension capability of OO languages

CISC 323, Winter 2003, Design Patterns 34

Advantage / Disadvantage

With a class adapter, all methods of exiting class are available:

CAQueue q = new CAQueue(); ... q.add(3, "third string");

This is an advantage if you want to be able to treat an object as both a queue and a linked list (a "two-way adapter") Disadvantage if you want to restrict the user to queue

• perations.

CISC 323, Winter 2003, Design Patterns 35

Efficiency

Object adapter may be slightly less efficient: two objects instead of one

• extra time for object creation, garbage collection
• extra space for bookkeeping info

A small difference, usually not significant

CISC 323, Winter 2003, Design Patterns 36

Relation to Quality Attributes

Modifiability

• Adapter class provides clean interface to clients of

adapted object – clearer therefore more modifiable Reusability

• Takes advantage of adapted class for reuse

Correctness

• Takes advantage of tested code

Performance

• May add slightly to execution time and memory use

CISC 323, Winter 2003, Design Patterns 37

Another Example: Displaying Lists

GUI packages in Java 1.1: AWT Newer GUI packages in Java 1.2: Swing Most components have same or similar interfaces; fairly easy to convert from AWT to Swing An exception: classes for displaying lists

• in AWT: List class
• in Swing: JList class

can display more kinds of lists (not just lists of Strings) different method names from List effect of one List method call can take several JList method calls Can't mix Swing and AWT components in same program

Example from Java Design Patterns by James W. Cooper

CISC 323, Winter 2003, Design Patterns 38

Situation

Your company has lots of old code written using AWT Many uses of AWT's List class Needs to update to Swing Swing programs must use JList, not List Could rewrite all code using List by hand:

• tedious job
• takes time (therefore money)
• lots of chance for errors

Better solution: use an adapter!

CISC 323, Winter 2003, Design Patterns 39

List/JList Adapter

AwtList interface includes all methods of old List class AwtListAdapter implements those methods using a JList User must change declarations from List to AwtListAdapter User doesn't have to change all the method calls