Design Patterns Trivia!

How confident are you in your design patterns?

Here's a site to test out your design patterns recognition - GoF design patterns quiz. This quiz is good to familiarize yourself with recognizing design patterns when you see them. Its not very good for judging when to use the pattern in your code or what problems it solves, but it does give you hints. You need to do match a given pattern with its name.

Here's an example - can you recognize what pattern this is?

Here are some hints:

• Recursive composition
• 1-to-1 'has a' up the 'is a' hierarchy
• Intent: Add additional responsibilities to an object dynamically

Any guesses?

Answer is Decorator Pattern.

Joel on Software

Ever heard of Joel on Software? Coming out of school you might not have heard of it and even for some years afterwards. I didn't know about it either until just recently. My boss made me take this software test The Joel Test: 12 Steps to Better Code.

Joel on Software is a weblog on software engineering. In short, it is the Office Space of software commentary coming from one person's experience - Joel Spolsky. When I say Office Space, I mean the movie and its witty comments about desk life and computer programmers in general. Mr. Spolsky uses witty commentary to keep his readers enthralled and in the process manages to make them understand some really neat tips for survival in the software world.

His logs have been converted into books but they are actually freely available on his website. I like his style of writing and his logs are an interesting read on any day. Its like reading Shakespearean comedy designed for software engineers, just much easier to understand. If you have ever read Much Ado About Nothing then you know what I mean. Its a good site to learn more about the non-academic aspect of software, aka the Real World.

Logic Puzzle

"You have 9 metal balls. 8 of them have the same weight, 1 is heavier than others. How can you find the 1 which weighs different from others in 2 steps?"

This was a question a friend of mine was asked in his interview. Its an interesting logical question and not something people might expect to be asked in an interview. Its easy to solve once you know how. My friend asked me this question, and I started of saying "divide the balls into 4,4 and, 1 and weigh them." Its the right way to solve the problem but turns out that my solution would take 3 steps to find the ball.

The right answer is dividing the balls into 3, 3 and 3. And weighing 1 group against another. If 1 group is heavier - that one has the ball. If the 2 groups weigh the same, the heavier ball is in the last group. Now take the group with the heavier ball, and apply the same idea with 1 ball against another. You have your ball now... and the answer to the question.

Presentations of Value

A professor of mine once gave a presentation on....well, presentations. She had attended a workshop on giving 'Good Presentations'. She had some good points that she discussed with class - some I agree to whole heartedly, while others...eh.

• Write the title of each slide in full sentences covering the topic of the slide.
• This was one of the ones that I'm not sure I fully agree with. A short topic title does the job of explaining what the slide is about just as well as a full sentence. I think the reasoning behind is that long presentations tend to bore people and they lose focus. When they come back, they can just read the title and understand where they are.
• Give an image on each slide.
• Oh I totally agree with this one. From my point of view - give an image even if you don't have text for that slide (Example - class diagram overview). In fact sometimes I find it better not to have text at all, just image and you can present it however you want.
• Do NOT write text on the slide in full sentences, just a brief description.
• I like this one. It saves a lot of space and gets the point across easier when you give the presentation.
  

This point is mine, from my experience (limited as it is)

• Spend as much time on your presentation slides, making them, remaking them, rewording them, organizing, outlining etc. as much as possible. Even if it takes a 1/2 day. Do NOT take it lightly thinking "Oh, presentation is easy, I can make the slides in 20 min".
• I say this because, the more time you spend on your presentation, the more you know of the material on it, the better you can present it. Which is better - constantly looking at the slides and interrupting yourself, nervous that you would forget what you are presenting, or, confidently presently, only occasionally glancing at the text to know your place? Believe me, I've done both and I found the latter more rewarding.
  

These points are actually only helpful when you are giving formal presentations. For more informal ones, there is no need to spend so much time, find images if a simple text can get your point across, and definitely no need for full sentences.

But if you are giving the presentation to a CEO of a company or your probable customers, it always pays to put a little more effort and make it worth THEIR while.

Design Patterns books

I have read a couple of books on Design Patterns. Whenever I read them it feels like the solution is given to you first and then the problem is explained. Now when designing software, you have the software and you have problems in the software. You don't automatically start thinking "oh yeah, I can use Strategy here" or "Maybe Observer can go here" unless you are trying to address a problem that may require the solution. So why isn't there a book out there that says something like "imagine you have a software that does so and so, how will you solve this?" and then it gives the solution(s) that may be applicable for the problem.

I was reading "Design Patterns for Dummies" by Holzner Steve, Ph.D recently. It comes pretty close to the style I was looking for. It explains the patterns in a form that can easily be remembered first and then goes into details with code. I have only read a couple of chapters in it but it seems easy enough to follow. The rest comes later...