Topics for Week 7

1
Object Design Design Patterns Hardware /
software platform defined ?
objects must now be implemented design
custom objects modify, reuse objects use
off the shelf components restructure,
optimize design
2
Design process (figure 6-2)
Nonfunctional requirements
Analysis
these include --use cases and
scenarios --class (ER) diagrams --sequence
diagrams --CRC cards --state diagrams

Dynamic model

Analysis object model
System design
Design goals guide trade-offs
We were here
Subsystem decomposition teams of developers
Object design
Object design model
Now were 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 objectsfor this particular
system Solution objectsmore 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 --specifications
ubtyping, 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 hashtablehashtable elements
contain keys which are NOT needed by set elements)
6
Specification inheritance formal
definition Strict 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 --Delegationan 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.
• Deitel, Appendix Q.
• 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 (1.1)

• 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

10
Design Patterns (2)

• 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

11
Design Patterns (3)

• 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

12
Design Patterns (4)

• 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

13
Design Patterns (5)

• 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

14
Design Patterns (6)

• Example IteratorJ. 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

15
Design Patterns (7)
Example Iteratorwhat variables will you
need? e.g. First itemtype Next
itemtype Current_item itemtype Is_done
boolean
16
Design Patterns (8)
In Java Enumeration functions like
Iterator Built into Vector class Hashtable
class
17
Design Patterns (9)

• 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?

18
Design Patterns (7.5)
Example Adapterwrap around legacy
code (Bruegge Dutoit, A.2)
Client
ClientInterface Request( )
LegacyClass ExistingRequest( )
Adapter Request( )
19
Design Patterns (9.5)
Heuristics for Selecting Design Pattermns (Bruegge Dutoit) 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
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 time Similar
to the concept of a macro, e.g. C
template C / Java / C generics Reference
comparison of C templates and Java
generics http//en.wikipedia.org/wiki/Comparison_
of_Java_and_C2B2B