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")

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" � or patterns in music: fugue, rondo, sonata � sometimes called "micro-architectures" CISC 323, Winter 2003, Design Patterns 2

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 3

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 4

Quality Attributes � Requirements analysis determines desired quality attributes of 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 5

Examples of Quality Attributes � Performance � Availability � Security � Modifiability � Usability � Testability CISC 323, Winter 2003, Design Patterns 6

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 7

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 8

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 9

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 10

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 11

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 12

Linked List Implementation One way to implement a queue: use a doubly-linked list of objects. front back A B C D Designate one end of the list as the front of the queue CISC 323, Winter 2003, Design Patterns 13

Linked List Implementation One way to implement a queue: use a doubly-linked list of objects. front back A B C D To enqueue Z: add it to the back of the list CISC 323, Winter 2003, Design Patterns 14

Linked List Implementation One way to implement a queue: use a doubly-linked list of objects. back front Z A B C D To enqueue Z: add it to the back of the list CISC 323, Winter 2003, Design Patterns 15

Linked List Implementation One way to implement a queue: use a doubly-linked list of objects. back front Z A B C D To dequeue: remove element from front of the list CISC 323, Winter 2003, Design Patterns 16

Linked List Implementation One way to implement a queue: use a doubly-linked list of objects. back Z A B C front To dequeue: remove element from front of the list (result is D) CISC 323, Winter 2003, Design Patterns 17

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 18

Bad Option: Ignore Interface You could make user use LinkedList directly (two ways): // create an empty queue LinkedList myQ = new LinkedList(); first element of list is // enqueue two tasks front of queue myQ.addLast(task1); myQ.addLast(task2); // dequeue a task Task t = (Task) myQ.removeFirst(); // create an empty queue myQ = new LinkedList(); // enqueue two tasks first element of list is myQ.addFirst(task1); back of queue myQ.addFirst(task2); // dequeue a task t = (Task) myQ.removeLast(); CISC 323, Winter 2003, Design Patterns 19

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 20

Object Adapter For a Queue <<interface> Queue +enqueue() +dequeue() +isEmpty() LinkedList OAQueue +addFirst() uses +enqueue() +addLast() client +dequeue() +removeFirst() 1 1 +isEmpty() +removeLast() +isEmpty() Sometimes called a "wrapper" – we're wrapping another object around a linked list to provide a different interface. CISC 323, Winter 2003, Design Patterns 21

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 22

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 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 // Removes task from front of queue. public Task dequeue() { return (Task) theList.removeFirst(); } // end dequeue 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 // True if queue is empty. public boolean isEmpty() { return theList.isEmpty(); } // end isEmpty } // end class OAQueue CISC 323, Winter 2003, Design Patterns 25

General Form of Object Adapter 1 CISC 323, Winter 2003, Design Patterns 26

Class Adapter For a Queue <<interface> Queue +enqueue() +dequeue() +isEmpty() LinkedList +addFirst() uses CAQueue +addLast() client +enqueue() +removeFirst() +dequeue() +removeLast() +isEmpty() Not multiple inheritance in Java: CAQueue extends a class and implements an interface. CISC 323, Winter 2003, Design Patterns 27

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 28