Martin Fowler Speak about Design Patterns

From my understanding, the main messages about his speak were:

• First thing to say is that I loved his presentation for many good reasons such as sense of humor, etc.
• He is currently writing a book about “Domain Specific Languages (DSL)”
• He said: What I am good at is to discuss and explore ideas and solutions with others...I am not expert in everything...I gather ideas/solutions from my colleagues too...

Domain Specific Languages:

The main idea is:

Domain Representation (e.g. XML) –> Structural Display Representation –> Final Display Representation (e.g. HTML)

(When I get access to the pictures I will post here)

Learning Process:

1. Novice


2. Advanced Beginner


3. Competent: A stage where you ask why and you understand whys. starting to understand patterns target this area.


4. Proficient: A stage where you understand the principles behind things


5. Expert: A stage where you start innovating

Pattern Definition:

A pattern is a solution to a problem in a context.

A pattern is not a Recipe, is not a Library and is not a Language.

Learning About Patterns:

• Learn from experienced developers; those who have done it before. It saves time.


• Learn from books such as Enterprise Application Architecture.


• Patterns are cross platform; java, c#, etc


• Know that each pattern can have many different variations depending on the context.


• Some people learn from Concrete (code example) to Abstract (design pattern) and some from Abstract to Concrete.

Pattern Parts:

Each pattern has 3 main parts:

1. Name: it's very important; it should be relevant, short and meaningful


2. How: how to implement this pattern


3. When/Why: understanding when and why you can use a particular pattern and when you shouldn't use them.

Support Understanding Patterns:

To support understanding each pattern:

• Prompt: the picture + description + UML model


• Example: to see examples how we can implement a pattern. Be variation-wise when looking at examples

Implementation of each pattern could have many variations depending on the context in which you would like to apply a certain pattern, so don’t rely on examples.

Avoid Unnecessary Complexity:

• Projects fail despite the latest technology for lack of ordinary solutions.


• Overusing patterns could be disastrous; unnecessary complexity


• Know when + why + how

Don't be Perfectionist:

Know that what you do today is always inadequate to your knowledge in the future.

Continuous Refactoring:

It's a matter of paying the Interest (when you just develop, debug or maintain) or paying the Capital (when developing and refactoring).

Chunking System/Focus:

You can't spend all your life learning about all the books and patterns. Often the best approach is to chunk the knowledge; focus on the solution to your specific problem and quickly find the pattern you need.

Pioneer in Design Patterns

Christopher Alexander is thought to be pioneer in design patterns.

One of his books is The Timeless Way of Building.

"Each pattern is a three part rule, whih expresses a relationship between a certain context, a problem, and a solution."

Links:

• His website
• Introduction to DSL
• His speaks on MSDN Channel9: http://channel9.msdn.com/posts/Charles/Jeffrey-Snover-Martin-Fowler-and-Neil-Ford-Domain-Specific-Languages/ and http://channel9.msdn.com/posts/Charles/Expert-to-Expert-Martin-Fowler-and-Chris-Sells-Perspectives-on-Domain-Specific-Languages/