So we can get a more formal and thorough understanding of what we now intuitively know and use.

A design pattern names, abstracts and identifies the key aspects of a common design structure that make it useful for creating a reusable object-oriented design.

Represent recurring problems and expert solutions. Allow novice programmers to learn from the experts experience. Lets us discuss and think about in concrete ways what was abstract. Originally applied to building design. At a certain level of abstraction. Help identify and model less obvious abstractions. Helps with object granularity (what should be an object). Helps decide what does and doesn't belong in a class's interface.

1. Pattern Name*: handle used to describe design problem, its solutions and consequences in a word or two. Gives us something to think about.
2. Pattern Class*: Purpose (Creational, Structural, Behavioral) & Scope(Class, Object)
3. Intent*: short statement of - What it does, Why it does it, and what problem it addresses. Scannable
4. Also Known As:
5. Motivation: A scenario that illustrates a design problem and how the pattern fixes it. Somewhat abstract.Applicability*: Quick list of when to use it. Scannable
6. Structure*: UML of the class structure or interactions.
7. Participants*: Names the classes and objects involved. Provides standard names for the various roles in a pattern.
8. Collaborations: CRCish list of interactions.
9. Consequences*: What this patterns means to the system it is used in.
10. Implementation: Tips and traps, variants.
11. Sample Code
12. Known Uses: Proves its worthy of being a pattern.
13. Related Patterns*: Frequently too short list of other patterns and there relationships. Alternative or frequently combined patterns listed here.

• Consider how design patterns solve problems
• Scan intent sections
• Study how patterns relate - and patterns of similar purpose
• Examine the causes needing redesign (see page 24 for causes and their solutions)
• Consider what needs to be variant and what is invariant. Encapsulate variance.

• Read the pattern once through for overview
• Study Structure, Participants and Collaborations sections
• Check out sample code for concrete examples
• Choose meaningful names for your pattern participants given context. May incorporate pattern names
• Define classes and their relationships
• Define application specific names for operations in the pattern
• Implement

• Composition vs. Inheritance vs. Generics: Example - any could be used to abstract comparison in sorting.
• Inheritance of implementation verses interface
• Delegation
• Indirection
• Abstraction
• Aggregation and Acquaintance- two possible object relations determined by intent.

• Composition: Filled Diamond. Whole/Part, but the contained object has the same life time as the container.
• Aggregation: Empty Diamond. Whole/Part, but the objects may not have the same life time.
• Association: No diamond. Represents the ability of one class to message another.

C++

Allows procedural or OO style. Primitive variables(char, int, bool, float, double etc), declarations, comments and operators (bitwise, logical, trinary) the same as Java. Blocks and functions. Same control constructs as Java (for, while, do while, if, switch, default, break, continue). Differences are that if doesn't require booleans. This allows = errors. Put variable on the right. Also no named break. Instead we have goto. Exception handling basically the same. Has namespaces instead of packages. They are more flexible but not as nice.

Discuss the separation of header and source files. Headers contain declarations while source contains definitions.

• include
• ifdef & ifndef
• endif
• define
• pragma once
• standard header style (because of the one definition rule.
• STL headers and std namespace

The extern C linkage convention. on a single declaration or a block

• DEFINES
• kConstants
• ClassName
• methodName
• propertyName
• //BUGBUG

jwalker@cs.oberlin.edu