Showing posts with label Design Patterns. Show all posts
Showing posts with label Design Patterns. Show all posts

Wednesday, July 9, 2008

Design patterns posting contract

All design patterns share a few properties, keen to describing a good design pattern and following are the properties Design Patterns – Elements of reusable object-oriented Software uses to describe design patterns, and therefore the ones I’ll be using on my posts, since that will be my main reference:

Name: All design patterns need a name and a good name is vital because it will become part of the vocabulary. If it’s the case, a second popular name (Design Pattern calls this “Also known as”).

Intent: What does the design pattern do? What problem does it address?

Motivation: A scenario that can state the importance of the pattern.

Applicability: In which situations can the design pattern be applied? Examples of poor designs the pattern can address and how to recognize those situations.

Structure: Graphical representation of the classes in the pattern. I will NOT be providing such graphical representations. Such images are copyrighted and I do not have permission from the authors to publish them.

Participants: Classes that participate in the design and their responsibilities.

Collaborations: How the participants work to accomplish their responsibilities.

Consequences: Trade-offs and results of using the design.

Implementation: Pitfalls, hints, techniques involved.

Sample code: Code fragments that illustrate how you might implement the design pattern. In my blog I’ll be giving those in C# 2.0 or 3.5 (I’ll point out which framework I’m using each time).

Known uses: Examples from the real world of complex systems that use the pattern.
Related Patterns: Closely related patterns, keen differences and patterns used in the design described.

Later this week, I’ll be posting the Abstract Factory description.
Regards.

Delicious Del.iciou.us

Monday, July 7, 2008

Design Patterns - what's the deal

As a tech lead in at Stefanini, one of my duties is to interview applicants and evaluate their technical knowledge. It's a very hard thing to do, once you realize that it's people’s lives, perspectives and needs that I'm dealing with when they come to us.

So after reading and testing skill after skill, applicant after applicant, here is one of the most common gaps: Design Patterns.

"If a colleague were to say to you, "Spouse of me this night today manufactures the unusual meal in a home. You will join?" three things would likely cross your mind: third, that you had been invited to dinner; second, that English was not your colleague's first language; and first, a good deal of puzzlement.

If you have ever studied a second language yourself and then tried to use it outside the classroom, you know that there are three things you must master: how the language is structured (grammar), how to name things you want to talk about (vocabulary), and the customary and effective ways to say everyday things (usage). Too often only the first two are covered in the classroom, and you find native speakers constantly suppressing their laughter as you try to make yourself understood.

It is much the same with a programming language. You need to understand the core language: is it algorithmic, functional, object-oriented? You need to know the vocabulary: what data structures, operations, and facilities are provided by the standard libraries? And you need to be familiar with the customary and effective ways to structure your code. Books about programming languages often cover only the first two, or discuss usage only spottily. Maybe that's because the first two are in some ways easier to write about. Grammar and vocabulary are properties of the language alone, but usage is characteristic of a community that uses it."

This extract from Effective Java's foreword, written by Guy Steele is the best way I've ever seen the need for programming patterns explained, so I decided to borough his words for this post. Surely you can express yourself and make the computer understand what you’re saying, but wouldn’t there be a better way to do so? Of course you can.

I decided to make a series of posts on the subject of design patterns. Since I don’t have any teaching training, I’ll be using one of the best books on this subject, the Design Pattern bible: Design Patterns, Elements of Reusable Object-Oriented Software by Erich Gamma, Richard Helm, Ralph Johnson and John Vlissides.

The first subject will be one of the simplest design patterns: the abstract factory.

Regards,

Delicious Del.iciou.us