Importance of knowing and talking Design patterns

As part of a push from a mate at work (and hopefully myself), I have started reading the book Head first design patterns by O’Reilly publishers (intro pdf avaliable on the site). By first looks, It’s a very childish book but once you get past the logic for it being so (well explained in the first few pages of the book/ pdf), it’s actually a really informative and invaluable book.


I have always thought that for me to pick up a good understanding of design patterns, I really have to be reading about them and implementing them as I go through the examples (prob the typical approach to learning). The way this book is written seems to remove this need by (according to the author) making use of different learning styles and ultimately making itself standout by use of images, with text and arrows inside the image rather then captions, images to stimulate emotion and attachment, lots of activities to practice and quiz yourself on your understanding, the use of stories which is a lot easier to remember then just raw information and facts and a lot more. End result is a much more interesting book that helps your brain persist, recall and hopefully apply the use of patterns in real life situations (the book gives heaps of good situations which relate somewhat to real world). So far the book is looking real good and I’ll highly recommend it to anyone who thinks they just wont be able to read a thick book on design patterns.


Anyway, back to my post, At the end of the first chapter, it talks about the huge importance and benefits of using a shared vocabulary when talking about software architecture, the vocabulary being mainly expressing  things in design patterns.
So fully supporting this comment, the key points and benefits of doing so (slightly grouped together and in 1 (longish) paragraph).

Saying more with less / Turbo charging the team / Stay in the design longer:
By using patterns to describe architecture, you are really describing and grouping together a whole pile of ideas which another developer should be able to understand without having to expand on the little details such as ‘this has a collection of animals which….”. By not getting into the details of how things are going to be implemented, you can easily form a stronger overview of the system and deal with the high level issues such as potential architecture floors. This also changes efficiency of the team (the whole turbo charge thing) by spending less time on actually explaining the individual components of a pattern (outside of the context of the pattern) and by minimising mistakes caused by misunderstanding and interpretation.

Once again, highly recommended book, easy to digest, Buy or Borrow this book!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: