Design Pattern Notes

On 2004-06-24, Alan Shalloway of Net Objectives gave a talk on design patterns at my then-employer. Here are my notes.

2004-06-24 – Patterns
Net Objectives -> Alan Shalloway, author of “Design Patterns Explained”
Boeing: Great internal education
Gang Of Four: Difficult book to understand
GOF: Using terms differently
AS: Looking at patterns differently, will also look at analysis
Adding functionality:
Where is the problem? Writing new code, integrating it into the system
Integrating is more difficult
Must accomodate change (not predict change):
identify special cases, abstract out commonalities, containing no more than one variation per class
Design from context: big picture to small, not small to big

Patterns can be architectural, design, idiomatic (language-specific)
Patterns describe relationships between entities (objects) in your problem domain,
handling variation and new ways of using inheritance come from inheritance

Patterns work on many levels: analysis/motivation, design, implementation
Think of them as “software patterns” – gives some “why” as well as “what”

use pre-existing solutions
some patterns deal with modifiability
design is not synthesis, but differentiation

3 perspctives:
– conceptual: what you want, requirements
– specification: interfaces of classes, how objects “talk” to each other
– implementation: code itself

Mop, broom and sponge: same and different
as specific object: different
as concept: all cleaning objects

abstract classes: concepts, never instantiated, define interfaces

person -> clean -> utensil interface (mop, broom, sponge)

encapsulation: ususally thought of as data hiding
can think of it as hiding classes -> derived classes
implementation hiding, type hiding, data hiding

Objects at different levels:
implementation: data with methods
specification: objects are contracts they implement
conceptual: entities with responsibilities

do not use inheritance badly
lots of switches (coupled) or inheritance
switches are coupled: if you must change one you have to change them all
sales tax: different class for each country

guidelines:
design to interfaces (interfaces in general sense)
favor object aggregation over class inheritance

consider what varies in design, encapsultate the concept that varies
– find what varies and encapsulate it in a class of its own
– contain this class in another class

use cases: “writing effective use cases”

cohesion: focusing on one thing
coupling: dependence of different actions

Commonality/variability analysis
From Jim Coplien – Multi-Paradigm Programming for C++
Thesis online
abstract: emphasize what is common, or ignore what is different
find commonalities relevant to problem domain

challenges in finging commonalities: we are data-centric,
objects usually thought of as “intelligent data”, instead of as behaviors
variability: makes sense only in a given commonality
frame of reference
it is a variation of commonality

commonality: gives architecture longevity
variability: makes it fit for use

commonality -> perspective (conceptual), specification -> abstract class, interfaces
variability -> implementation, specification -> concrete classes

patterns are about relationships

Matrix for CVA

case 1 case 2 case 3
behavior 1   implementations for behavior 1
behavior 2   implementations for behavior 2

Look at patterns in terms of their motivations, not just what they do
switches are okay if they are in one place
can use abstract factory to instantiate the implementations – separates construction from use
Joshua Bloch: Effective Java

www.netobjectives.com/dpe2nd – go to seminars too
Timeless Way of Being: Alexander
ezine: info @ netobjectives.com – subscribe

Image from Wikimedia, assumed allowed under Fair Use. Image from the Vatican Virgil, a 5th century manuscript of poems by Virgil.