Class 35: Design Patterns (1): Introduction

Held: Monday, 22 November 2004

Summary: Today we begin our exploration of the Design Patterns philosophy.

Related Pages:

• EBoard.

Assignments

• Finish your simulation (due Monday, 6 December 2004).
• Read chapter 2 of Design Patterns (due Wednesday, 24 November 2004).
• Read chapter 3 of Design Patterns (due Monday, 29 November 2004).

Overview:

• Multiple perspectives on software reuse
• The Design Patterns philosophy
• An example: Sorting
• The Design Patterns catalog, abbreviated
• The Patterns Format(s)

Multiple perspectives on software reuse

• Good software design often involves reuse
  • We try to use code that's been written previously
  • We try to design code that can be used again
• Why reuse?
  • It speeds up programming (or at least it can)
  • It can help improve the quality of programs (if the reused parts are well tested)
  • It can improve the maintainability of programs (changes propagate easily)
• There are a number of ways we can reuse code
  • We can copy and paste code from one program to another
  • We can factor common code into a procedure
  • We can put related frequently-used procedures into a library
  • We can put related frequently-used ADTs and Data Structures into a library
  • We can put related classes into a library
  • We can build the skeleton of a particular kind of program and leave stubs to be filled in for a particular version (the DP book calls these frameworks)
  • We can identify heuristics that guide us in the development of code (reusing design knowledge, rather than code)
  • ...

The Design Patterns philosophy

• The Design Patterns philosophy suggests that we can reuse fairly high-level strategies for design without reusing particular code.
• A strategy identifies a programming "problem" and a typical way that the problem is solved well.
• You may find that multiple patterns apply to the same problem; in this case it's your job to decide which is best for your particular situation.
• Like heuristics, patterns are guides, not rules.
• Warnings!
  • The DP book is much like any philosophy text: It is quite self-referential, and it is unlikely you will understand everything on the first (or second or ...) reading.
  • I will admit that I am not intimately familiar with the DP book. (I know most of the patterns from my other reading.)
  • There are multiple perspectives on what a "pattern" is.

Some Patterns from Scheme

• When programming in Scheme, we consciously or subconsciously identified some important patterns.
• Build a new list by doing something to every element of a list
• Compute a compound value based on the elements of a list
• One of the nicer aspects of Scheme is that you can encapsulate these patterns in code (perhaps making them a template).

An example: Sorting

• To see that many patterns can apply to the same problem, let us consider the problem of generalized sorting (writing a sorting algorithm that applies to different types and permits different orderings of the same type).
• We can accept the comparator as a parameter to the sorting routine (I'd call this a "higher-order" pattern).
• We can leave a stub for the comparison and require that programmers subclass the sorting class to include a new comparison function.
• We can require the data to provide its own comparison function. When we want data to compare itself differently, we must subclass the data.

The Design Patterns catalog, abbreviated

• See pp. 8-9 of the book.

The Patterns Format(s)

• A high-level overview:
  • Name
  • The problem
    • How do I do X?
    • I've done Y, how can I do it better?
    • My program requires Z1, Z2, and Z3. What pattern applies?
  • The solution
  • The consequences
• The low-level details (pp. 6-7)
  • Name
  • Classification
  • Intent
  • AKA
  • Motivation (example)
  • Applicability
  • Structure
  • Participants
  • Collaborations
  • Consequences
  • Implementation problems
  • Sample code
  • Real-world examples
  • Related patterns