Patterns

1
Patterns
2
Components of Patterns

• pattern name
• problem - describes when to apply pattern
• problem context
• conditions which must be met
• solution
• elements making up design, relationships,
  responsibilities, collaborations
• consequences
• results trade-offs

3
Types of Patterns To Be Studied

• descriptions of communicating objects classes
• customized to solve a general design problem in a
  particular context

4
Describing Design Patterns

• pattern name classification
• intent
• problem addressed
• also known as
• motivation
• scenario - motivating example
• applicability
• situations in which pattern can be applied

5

• structure
• graphical representation
• class diagram sequence diagrams
• participants
• classes responsibilities
• consequences
• implementation
• sample code
• known uses
• related patterns

6
How Design Patterns Solve Design Problems

• finding appropriate objects
• decomposing system into objects
• difficult part of oo design
• many methods of attack
• can come from analysis model or from computer
  implementation
• design patterns - help identify less obvious
  abstractions

7

• determining object granularity
• different patterns describe how to handle objects
  at different levels of granularity
• specifying object interfaces
• interface - set of all signatures for objects
  operations
• type - name used to denote a particular interface
• design patterns - help identify key elements
  kinds of data that get sent across an interface
• can specify what not to put into interface
• can specify relationships between interfaces

8

• specifying object implementations
• implementation - defined by its class
• object - created by instantiating a class
• new classes - can be created from existing class
  using class inheritance
• subclass - inherits from parent class -
  definitions of all data operations
• abstract class - define common interface for its
  subclasses
• cannot be instantiated
• concrete class - can be instantiated
• subclass - can override an operation defined by
  parent class
• mixin class
• provide interface or functionality to another
  class
• requires multiple inheritance

9

• class vs. interface inheritance
• class - defines how object is implemented
• internal state implementation of operations
• type - refers only to interface
• ? object can have many types objects of
  different classes can have same type
• C Eiffel - use classes to specify both types
  implementation
• class inheritance
• defines object's implementation in terms of
  another object's implementation
• ? code representation sharing
• interface inheritance - subtyping
• an object can be used in place of another
• C Eiffel - inheritance means both

10

• programming to an interface
• fundamental principle of oop
• for true inheritance - all derived classes will
  share inheritance with abstract class
• ? all subclasses can respond to requests made to
  interface of abstract class
• benefits
• clients remain unaware of types of objects they
  use - as long as object adhere to interface
• clients remain unaware of classes that implement
  these objects
• implementation dependencies between subsystems -
  reduced
• dont declare variables to be instances of a
  concrete class - instead, commit only to
  interface defined by an abstract class

11
Putting Reuse Mechanisms to Work

• inheritance vs. composition
• inheritance - "white box" reuse
• internals of parent class - often visible
• composition - "black box" reuse
• no internals visible
• advantages of inheritance
• defined statically at compile time
• supported by programming language
• easy to modify implementation being reused -
  override operation

12

• disadvantages of inheritance
• cannot change inherited implementation at
  run-time
• parents frequently define part of representation
• ? don't have complete encapsulation of
  representation
• 1 possible solution - inherit from abstract class
• composition
• defined dynamically at run-time
• only access interface ? not break encapsulation
• class hierarchies - remain smaller
• more objects in design
• favor object composition over class inheritance

13

• delegation
• makes composition as powerful for reuse as
  inheritance
• receiving object delegates operations to delegate
  object
• main advantage - easy to compose behaviors at
  run-time to change the way they are composed
• disadvantage - harder to understand than static
  software
• inheritance vs. parameterized types
• parameterized types - define type without
  specifying all other types it uses

14
Relating Run-Time Compile-Time Structures

• run-time structures - little resemblance to code
  structures
• code structure - classes in fixed inheritance
  relationships
• run-time structure - rapidly changing networks of
  communicating objects
• aggregation acquaintance (association)
• both implemented (frequently) as pointers
• ? look the same at compile-time
• run-time - act differently
• some design patterns help capture differences

15
Designing for Change

• need to anticipate new requirements changes to
  existing requirements
• class redefinition reimplementation
• client modification
• common causes of redesign
• creating an object by specifying a class
  explicitly
• class name - commitment to particular
  implementation
• create objects indirectly

16

• dependence upon specific operations
• specific operation - commit to 1 way of
  satisfying request
• avoid hard-coded requests
• dependence on hardware software platform
• harder to port
• patterns - limit dependencies
• dependence on object representations or
  implementations
• clients change if object implementation changes
• hide representation implementation
• algorithmic dependencies
• objects depending upon algorithm - change if
  algorithm changes
• isolate algorithm

17

• tight coupling
• classes which are tightly coupled - hard to reuse
  in isolation
• loose coupling - increase chance of reusing
  individual classes
• extending functionality by subclassing
• modifying 1 operation might require modifying
  other operations
• need to understand linkage
• object composition - delegation - more flexible
• inability to alter classes conveniently
• some design patterns can handle this
• application programs
• internal reuse, maintainability, extension - high
  priorities

18

• design patterns can
• reduce dependencies
• encapsulate operations
• encapsulate algorithms
• limit platform dependencies
• toolkits
• set of related reusable classes - general
  purpose functionality
• frameworks
• set of cooperating classes - reusable design for
  a specific type of software
• customize framework by creating application
  specific subclasses of abstract classes

19

• dictates architecture of application
• overall structure
• partitioning into classes objects
• collaboration of classes objects
• thread of control
• emphasize design reuse
• differences between design patterns frameworks
• design patterns are more abstract
• frameworks - directly implemented in code
• design patterns - smaller architectural elements
• design patterns - less specialized
• frameworks - specific application domain