Patterns and Reuse

1
Patterns and Reuse
2
Patterns

• Reuse of Analysis and Design

3
Patterns

• Patterns describe common ways of doing things.
• They are collected by people who spot repeating
  themes in designs.
• They take each theme and describe it so that
  others can use it.
• They capture the static and dynamic structures
  and collaborations of successful solutions to
  problems that arise when building applications in
  a particular domain.

4
Patterns of Learning

• To be good at chess, you have to
• Know the rules.
• Learn the principles.
• Observe past games that were played (patterns).
• To become a good software engineer you have to
• Know the rules.
• Learn the principles.
• Observe past systems that are written (patterns).

5
Patterns

• Patterns problem/solution pairs in a context
• They capture the static and dynamic structure and
  collaboration among key participants in software
  design
• They facilitate the reuse of successful software
  architectures and designs.

6
Patterns

• A pattern is much more than a model.
• It must contain the reason why it is the way it
  is.
• The pattern must
• Make the problem clear.
• Explain why it solves the problem.
• Explain in what circumstances it works.
• Explain in what circumstances it does not work.

7
Design Pattern Descriptions

• Main parts
• Name and intent
• Problem and context
• Requirements addressed
• Abstract description of structure and
  collaborations in solution
• Positive and negative consequences of use
• Implementation guidelines and sample code
• Known uses and related patterns

8
Design Pattern Descriptions

• Pattern descriptions are often independent of
  programming language or implementation details.

9
When to Use Patterns

• All the time.
• When trying to develop something in
• Analysis.
• Design.
• Coding.
• Project management.
• Search for any available patterns that might help
  you.

10
Example Problem

• You have objects running in a process on your
  desktop.
• They need to communicate with other objects
  running in another process.
• (Maybe on your desktop, maybe elsewhere).
• You dont want the objects in your system to have
  to worry about finding other objects on the
  network or executing remote procedure calls.

11
Solution

• Create a proxy object within your local process
  for the remote object.
• This has the same interface as the remote
  object.
• Your local objects talk to the proxy using the
  usual in-process message sends.
• The proxy is responsible for passing any messages
  on to the real object, wherever it may reside.
• Proxies are a common technique used in networks
  and elsewhere.

12
Reusing Experience

• Proxies have been used over and over again.
  People know
• How they can be used.
• Their advantages.
• Their limitations.
• How to implement them.
• Proxy as a design pattern describes a design
  technique.

13
Documenting Patterns

• The general form for documenting patterns is to
  define items such as
• The motivation or context that this pattern
  applies to.
• Prerequisites that should be satisfied before
  deciding to use a pattern.
• A description of the program structure that the
  pattern will define.
• A list of the participants needed to complete a
  pattern.
• Consequences of using the pattern...both positive
  and negative.
• Examples!

14
Sample design pattern

• In an ordering system, we often see the following
  pattern

15
Patterns and Frameworks

• Patterns support reuse of software architecture
  and design
• Frameworks support reuse of detailed design and
  code.
• A framework is an integrated set of components
  that collaborate to provide a reusable
  architecture for a family of related
  applications.
• Together, design patterns and frameworks help to
• Improve software quality
• Reduce development time.

16
Frameworks

• These are semi-complete applications.
• Complete applications are developed by inheriting
  from and instantiating parameterised framework
  components.
• Frameworks provide domain-specific functionality.
• e.g. business applications, telecommunication
  applications, window systems, databases,
  distributed applications, OS kernels.

17
Frameworks

• Exhibit inversion of control at run-time
• i.e. the framework determines which objects and
  methods to invoke in response to events.
• Microsoft Office is a framework.
• Note the common patterns that are in use in this
  framework.

18
PowerPoint screen
19
Word screen
20
Excel screen
21
Game framework

• Tic-tac-toe and Chess.
• In both cases
• The game is played by two players
• The game is played on a square, squared board.
• Players move alternately.
• To make a move is to alter the state of the board
  by adding, removing and / or moving some tokens,
  which are things on the board.

22

• Any token on the board is owned by one or other
  player.
• All relevant information is available to both
  players.
• Which moves are legal depends on the state of the
  board - which tokens are where- possibly together
  with other factors like the history of the play.
• Who wins depends on the same factors.

23
Chess game
24
Tic Tac Toe game