Design patterns discussed:

Singleton (mostly evil - if you think you want to use this "pattern", you should probably think again. Often something that seems like there should be only 1, turns out not to be the case. E.g. toolbar, database. Encourages lack of control of the dependencies within an app as any class can grab the singleton directly.)

Command (adding to a plan - points, lines, squares)

Composite (composing commands together)

Decorator (decorating a command to make a 'background thread' command)

Facade (simple interface to specific groups of WPF controls (panel.AddQuestion().AddChoice("A").AddChoice("B"))

Adapter (e.g. can be used to provide a uniform interface to disparate subsystems)

Strategy (alternative to (duplicated) case statements)

(Abstract) Factory (alternative to direct use of 'new' enables testing, allows easy switching from one group of object to another (e.g. SqlServer vs. Oracle) without affecting client code

Flyweight (sharing a single immutable (no state) object between multiple clients. E.g. multiple text runs in a word processor share the same 'bold' object. DotNet does this for string constants - multiple identical string constants are represented as the same object.

General Comments:

Design patterns are descriptions of how software can be structures. They are not means to enforce rules, such as "only the factory can create objects of type X".

Design patterns are often used together, e.g. Factory to create a strategy.

Questions:

Dependency Inversion vs. Inversion of Control - what is the distinction?

Audio : designPatterns.wma