1

Object Design & Design Patterns

Hardware / software platform defined objects must now be implemented

design custom objectsmodify, reuse objectsuse off the shelf components

restructure, optimize design

2

Analysis

Design process (figure 6-2):

System design

Object design

Nonfunctional requirements

Dynamic model

Analysis object model

Design goals—guide trade-offs

Subsystem decomposition—

teams of developers

Object design model

**

*: these include

--use cases and scenarios

--class (ER) diagrams

--sequence diagrams

--CRC cards

--state diagrams

We were here

Now we’re here

3

Four basic activities, occurring CONCURRENTLY:

Reuse:--off the shelf components, class libraries, basic data structures and services--Design patterns used for standardization--Custom wrappers may be needed

Interface specification (API---application programmer interface):--may also identify additional objects for data transfer

Restructuring:--simplify, increase reuse if possible

Optimization:--mostly addresses performance issues

4

Reuse:

Application objects—for this particular system

Solution objects—more general, e.g., data storage, interfaces, etc.

Off-the-shelf: IP (Intellectual Property)“off-the-shelf” components may be attractive to reduce development time, but they may cause problems for later implementations if they are discontinued or if they are modified by their owners

5

Simplification process:

Inheritance: a powerful method for simplification

Inheritance used properly supports later modifications well

But inheritance must model a true taxonomy

4 types of inheritance:

--Specialization: detected during development of a specialized class

--generalization: common properties abstracted from several classes

--specification—subtyping, supports code reuse

--Implementation inheritance: for the sole purpose of reusing code; objects not conceptually related (e.g., example in chapter 8 of set implemented as a derived class of “hashtable”—hashtable elements contain keys which are NOT needed by set elements)

6

Specification inheritance: formal definitionStrict inheritance (Liskov substitution principle): basically, a method written in terms of a superclass T must be able to use instances of any subclass of T without knowing these are instances of a subclass

Implementation inheritance / delegation:

--Delegation—an alternative to implementation inheritance

--Implemented by sending a message to the delegate class

--Leads to more robust code

--Between implementation and delegation, it is not always clear which is the best choice

7

Another solution, design patterns:

design pattern: available to solve recurring problems in coding. A design pattern has:

--descriptive name

--problem description

--solution (classes and interfaces)

--consequences (trade-offs and alternatives)

Examples: Appendix A

8

Design Patterns:

References: 1. Gamma, Helm, Johnson, and Vlissides, Design Patterns,

Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995.

2. Deitel, Appendix Q.3. Bruegge & Dutoit, Appendix A

useful for experienced oo programmers--”what worked well in the past” for common oo programming problems

many examples of design patterns can be found in the literature and on the web

9

Design patterns and alternatives:

• Start from scratch: you are writing a novel piece of code

• Use a library component: you have a library component which does the job

• Use a design pattern: you need something not provided by a library component, but the basic functionality is very similar to a library component or to a frequently seen programming task

With design patterns, you get a “head start” on your coding and you should be able to spend less time debugging

Design Patterns (1.1)

10

3 basic types of design patterns are usually defined:

•creational--common methods for constructing objects

•structural--common ways of resolving questions about interobject relationships

•behavioral--common ways of dealing with object behavior that depends on context

Design Patterns (2)

11

Some common creational design patterns:

•abstract factory--creates a set of related objects

•builder--keeps details of data conversions, if different data types supported

•factory method--defines interface for creating a method, rather than a specific method

•prototype--gives prototypical instance for object creation

•singleton--ensures that only one instance of class is created; provides global access point

Design Patterns (3)

12

Some common structural design patterns:

•adapter--translates between interacting objects with incompatibilities

•bridge--flexible method for implementing multiple instances of abstract class

•composite--hierarchical grouping of different numbers of objects from varying classes

•decorator--wrapper around original object, with additional dynamic features

•façade--standard front end for a series of classes

•flyweight--allows sharing to support many fine-grained objects efficiently

•proxy--delays the instantiation of the class until the object is needed

Design Patterns (4)

13

Some common behavioral design patterns:

•chain of responsibility--give objects in a chain of objects a chance to handle a request

•command--encapsulate request as parameterized object; allow undoable commands

•interpreter--define a method for each rule in a given grammar

•iterator--access elements of an aggregate object, keeping representation private

•mediator--holds explicit object references for classes that would otherwise be highly coupled

•memento--store an object state for checkpoints or rollbacks

•observer--all instances will be notified of changes to the observed class

•state--behavior of an object can depend on the state it is in

•strategy--set of related algorithms for a certain problem

•template method--details of the algorithm are left to subclasses

•visitor--allow new operations to be defined on an object structure without changing classes on which they operate

Design Patterns (5)

14

Example: Iterator—J. Cooper, (Behavioral Patterns)

• move through a collection of objects (array, linked list, ….) without knowing detailed internal representation

• may only return certain objects in the collection, based on a user-specified criterion

Design Patterns (6)

15

Example: Iterator—what variables will you need?e.g.:

First: itemtype

Next: itemtype

Current_item: itemtype

Is_done: boolean

Design Patterns (7)

16

In Java:

Enumeration functions like Iterator

Built into:Vector classHashtable class

Design Patterns (8)

17

Class design issues:

• If another thread changes the data while Iterator is active what should happen?

• How much access does Iterator need to internal data structures to do its job?

Design Patterns (9)

18

Example: Adapter—wrap around legacy code(Bruegge & Dutoit, A.2):

Design Patterns (7.5)

Client

ClientInterface

Request( )

LegacyClass

ExistingRequest( )

Adapter

Request( )

19

Design Patterns (9.5)

Heuristics for Selecting Design Pattermns (Bruegge & Dutoit)

--”Manufacturer independence”--”Platform independence”

Abstract Factory

--”Must comply with existing interface”--”Must use existing legacy component”

Adapter

--“Must support future protocols” Bridge

--“All commands should be undoable”--”All transactions should be logged”

Command

--”Must support aggregate structures”--”Must allow for hierarchies of variable depth and width”

Composite

--”Policy and mechanisms must be decoupled”--”Must allow different algorithms to be interchanged at runtime”

Strategy

20

Templates / Generics:

Another way to improve productivity“parameterized item”

Example: if we are designing a processor, we might want to specify a register to hold n bits;We want to declare registers of different lengths, so we use a parameterized version, where the specific value of n can be substituted at compile timeSimilar to the concept of a macro, e.g.

C++: templateC++ / Java / C#: generics

Reference: comparison of C++ templates and Java generics:http://en.wikipedia.org/wiki/Comparison_of_Java_and_C%2B%2B

Templates / Generics