Catalog of Design Patterns

1. Abstract Factory - provides an interface for creating families of related or dependent object without specifying their concrete classes.
2. Adapter - converts the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.
3. Bridge - decouples an abstraction from its implementation so that the two can vary independently.
4. Chain of Responsibility - Avoids coupling the sender of a request to its receiver by giving more than one object a change to handle the request. Chain the receiving objects and pass the request along the chain until an object handles it. {Could this be use in AI?}
5. Command - encapsulates a request as an object, thereby letting me parameterize clients with different requests, queue or log requests, and support undoable operations.
6. Composite - composes objects into tree structures to represent part-whole hierarchies. Composite lets clients treat individual objects and compositions of objects uniformly.
7. Decorator - attach additional responsibilities to an object dynamically. Decorators provide a flexible alternative to subclassing for extending functionality.
8. Facade - provides a unified interface to a set of interfaces in a subsystem. Facade defines a higher-level interface that makes the subsystem easier to use.
9. Factory Method - defines a interface for creating an object, but lets subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
10. Flyweight - is used to support sharing a large number of fine-grained object efficiently.
11. Interpreter - given a language, define a represention for its grammar along with interpreter that uses the representation to interpret sentences in the language.
12. Iterator - provides a way to access the elements of an aggregate object sequentially without exposing its underlying representation.
13. Mediator - defines an object that encapsulates how a set of objects interact.
    

{more to be done}

Describing Design Patterns

Pattern Name and Classification

Intent

Also Known As

Motivation

Applicability

Structure

Participants

Collaborations

Consequences

Implementation

Sample Code

Known Uses

Related Patterns

Model/View/Controller (MVC)

The Model/View/Controller is used in Smalltalk and is an example of an Observer design pattern.

It also contains the Composite design pattern.

Four Essential Elements to a Design Pattern

1. Pattern Name - the handle used to describe a design problem, its solutions, and consequenes. Allows design at a higher level of abstraction.
2. Problem - describes when to apply the pattern. Describes the problem and its context.
3. Solution - describes the elements that make up a design, their relationships, responsibilities, and collaborations. A template that can be applied in many different situations. Provides an abstract description of a design problem and how a general arrangement of elements (classes and object) solves it.
4. Consequences - the results and trade-offs of applying the pattern. Critical in evaluating design alternatives and understanding the costs and benefits of applying the pattern.
   

Discusson of Software Engineering

I love anti-patterns. I see so many of them in the work I do :-)

http://en.wikipedia.org/wiki/Anti-pattern

Curt:

http://duartes.org/gustavo/blog/post/2008/02/20/Richard-Feynman-Challenger-Disaster-Software-Engineering.aspx

• Engineering can only be as good as its relationship with management
• Big design up front is foolish
• Software has much in common with other engineering disciplines
• Reliable systems are built by rigorously tested, incremental bottom-up engineering with an 'attitude of highest quality'

Danny:

If it is anything that I have found, it is that a purist approach in any discipline is probably wrong.

Full up design up front is too rigid for software, true. But, complete bottom up, focuses too much on details and too litle on direction. Both can turn out disasters.

Robert:

From Steve McConnell’s Code Complete:

“In the final analysis, top-down and bottom-up design aren’t competing strategies–they’re mutually beneficial. Design is a heuristic process, which means that no solution is guaranteed to work every time. Design contains elements of trial and error. Try a variety of approaches until you find the one that works well.”

Me:

Perhaps we should be looking for Anti-patterns like ‘Golden hammer’ and ‘Silver bullet’?

(See http://en.wikipedia.org/wiki/Anti-pattern)