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.


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.



Wednesday, July 2, 2008


This is a very short post I decided to write so that I can apologize to you, fellow reader.
In no way this is a justification for such a long hiatus between posts, it’s simply an informative post, so that you have an idea of the reasons.
First of all, my project at Dell has been taking all of my time lately with very few exceptions, which I’ve been using to catch up with my sleeping. Things have gotten complicated and let’s just say I’m hoping for a fast solution that will give my team and me some time to organize our thoughts and goals.
Second, because of my lack of spare time, I haven’t got the chance to play with VS2008, but I am writing a visualization project so that I can test the new framework features. There’s not much of it ready for implementation, but I’m inclined to build something related either to conversations through MSN Messenger and/or e-mails (special thanks for the class of 2007 for the relentless mails about soccer games, barbecues, lemons, etc...) or something related to my sports injuries – I’d like to take this moment to mention Tim and his visualization of injuries "Where does it hurt?" posted at his blog, which has inspired me to build something on the same sense.
So, I hope you guys can find it in your hearts to forgive me for the absent and please give me an input as to which of the visualizations would be more interesting.

Thank you.