Design Patterns Explained

Alan Shalloway, James Trott

Mentioned 14

A thoroughly-revised and timely second edition to one of the most successful introductory design patterns books on the market.

More on Amazon.com

Mentioned in questions and answers.

I'm a confused newbie and hobbyist programmer trying to get a grip on this, so forgive me if my question is a little off or doesn't make much sense.

I see a lot of questions on SO revolving around the use of design patterns, and I'm wondering if anyone has a good resources for learning about, and implementing design patterns? I understand the general idea, and know how/when to use a couple of them(Singletons, Factory methods) but I know I'm missing out.

(Just in case it matters, my language of preference is C# but I could learn from examples in other languages)

Applying UML and Patterns by Craig Larman. Start from the basic of analysis, design and uses a simple Case scenario. Introduces most of the basic patterns in a simple way.

An introductory book that I found useful and well written is Design Patterns Explained by Alan Shalloway and James Trott (Addison Wesley).

alt text

Do not start from the Gang of Four book, for it is not an introductory book by any means.

The original Design Patterns book is a must-read for all programmers.

It is an excellent book on every level: layout, clarity, insight, depth. It's one of those great books that you first read cover-to-cover, and then use as a reference until you literally know it inside out.

You could start by the Wikipedia page, but treat yourself with the great book too.

Before spending money on books I would recommend Wikipedia's excellent design patterns page. Also for something different Google for "design pattern screencasts" or search for "design patterns" on YouTube. Getting the same information presented differently often helps the penny drop.

The Gang of Four book is the definitive text on the most well known patterns but is not that easy to read and with C++ examples not everyone's favourite.

The Head First Design Patterns text is far more accessible but only contains a subset of the Gang of Four patterns.

The most important thing is to understand where and why a particular pattern is useful. Afterwards search the web for implementation examples in the language of your choice and experiment until you "get it". Understand one pattern before moving on to the next. Everyone understands some patterns better than others (and there are hundreds of lesser known ones).

Just keep plugging away.

Design patterns are great for various reasons:

  1. gives you a starting for solving common problems.
  2. gives developers a vocabulary to talk about certain ways of solving problems in a very compact manner.
  3. when working with developers who know design patterns and you use design patterns in your solutions they will understand the solutions a lot faster.

But when your goal is just to learn design patterns I think you are missing the fundamentals. All design patterns are based on more common principles. High Cohesion, Low Coupling Open Closed Principle, DRY, Liskov Substitution Principle etc. For these fundamentals I would read the following books in this order:

  1. Head First Object-Oriented Analysis and Design (Head First) [ILLUSTRATED] (Paperback)
  2. Applying UML and Patterns (Hardcover)
  3. Agile Principles, Patterns, and Practices in C# (Robert C. Martin Series) (Hardcover)

After that you are ready for the basic gang of four design patterns

  1. Head First Design Patterns (Head First) [ILLUSTRATED] (Paperback)
  2. The BIBLE
  3. A nice website (don't buy anything, it is not worth it) http://dofactory.com/Patterns/Patterns.aspx (some implementations of this site are worth a discussion

The next step:

  1. Patterns of Enterprise Application Architecture (Addison-Wesley Signature Series) (Hardcover)
  2. The POSA books

And always remember : the pattern is not the goal !

Head First Design Patterns

alt text

and the Design Pattern Wikipedia page are the best resources for beginners. FluffyCat is another good, free online resource for design patterns in both Java and PHP.

The Gang of Four book is where to go afterward, but it's fairly advanced, so I'd wait until you have a pretty firm grasp from the other resources.

I'd add that Design Patterns book from the "Gang of four" is a bible for anyone who is seriously interested in design patterns.

I need some help from more experienced programmers. I want to improve my MVC skills. But I could not find a good tutorial on Google for MVC. Google always gives "MVC for beginners".

I understand what MVC is and I can make it, but I'm not experienced enough to do something practical in OOP.

If anyone knows a good object-oriented tutorial for MVC, please direct me to the right place — I'm looking for good links, books etc.

Links, that contain PHP-only materials, are marked with php for easier identification.

You cannot even begin to delve into MVC before you have comprehensive understanding of OOP. That include OOP practices (dependency injection, unit testing, refactoring) principles (SOLID, SoC, CQS, LoD) and common patterns (and no, singleton is not an object-oriented pattern).

MVC is an advanced architectural design pattern, which requires solid understanding. It is not meant for beginners or for tiny "hello world" applications. One uses MVC to add additional constraints to the codebase, when simple adherence to OOP practices becomes too loose to control the codebase.

The best I can suggest for you would be to begin by expanding you knowledge regarding object oriented code:

The two lectures above should cover the basics. And then move on to:

When you understand all that was explain in this series, you can expand on:

Also, I would strongly recommend for you to read (in this order):

P.S.: you might also take a look at this book (cautiously, because it has issues): Guide to PHP Design Patterns php

I work for an organization that is pretty much a start-up within a large corporation. The team has several database engineers, and a few software engineers (in the data mining field). We're growing at a fast rate, which puts the need to have an overall architecture strategy or technology roadmap (or compass) for the next few years. As a software engineer, I've been assigned the task to start off on bi-monthly meetings to lead that discussion. So, my question is, how do you kick-off your role as an architect? how do you start off an organization-wide architecture discussion? I started reading the book "97 Things Every Software Architect Should Know", but I'd like to hear more from your experiences. So, as an architect, how did you start?

Best regards,

This is less from experience and more from practical thinking. First of all it's difficult to define software architecture - a great reference to start is always 'design patterns explained' as this takes a non-software approach to understanding architecture.

Start looking at specific core issues of architecture such as

  • Commonality and variability
  • separation of concerns
  • aggregation over abstraction

Architecture is not about removing complexity rather it's about managing it. So start by understanding the issues that comprise complexity in the context of your project

Your question is a hard one because it touches on many areas: process, leadership, and software design (or architecture). I'm going to assume you have a standard process already, but if you don't then try one of the Agile processes. I'll talk about leadership and software architecture.

Leadership. Fred Brooks' great book, The Mythical Man-Month, talks about having a technical leader the way a surgical team has a leader. Personally, I like more collaboration than I see with doctors, so let's treat Brooks's surgical team as an extreme. Still, you need someone to technically coordinate who is doing what, things like allocating people to work in different parts of the system, deciding what the hardest (riskiest) parts are (so that they don't get deferred until they're expensive to change/fix), and make choices when the team disagrees. This kind of technical leadership is needed whether you are building software, cars, or pogo sticks.

Architecture/Design. The standard mantra is that "Every system has an architecture" but the corollary is that not every architecture is deliberately chosen. You may implicitly copy the architecture from your last project, say a 3-tier system. Or it may be pre-decided once you know you're using a framework like EJB. At the beginning of a project, you'll be making architectural decisions and some will be hard to change later. How will you persist data? Will you use a framework (eg Spring, EJB, RoR)? Will you process data incrementally or in batch?

Pretty much any architecture can be forced to meet your requirements. For example, you could use RoR to build an thermostat. But you'll have an easier time when your architecture is a good fit for the requirements. Sometimes you'll have requirements, such as low user interface latency, that can be helped out by a wise architecture choice, like using AJAX. So the beginning of your project is an opportunity to think about these things and get them right. (And this doesn't mean you go up to the mountain, think hard, then dictate your answers to the team -- here again I favor collaboration).

Don't be afraid to think about architecture up front, especially about ways it can help you avoid difficulties, but also don't try to decide everything in advance. You'll have trouble if one part of your team started using Ruby on Rails while another part started using EJB -- so make some technical decisions, the ones that are forced on you and the ones that will address your biggest risks.

One last thing: Early architecture discussions are a blessing and a curse. They are a blessing in that they get ideas out early and allow you to choose your design rather than blunder into it. But they are a curse in that everyone will have opinions, and it can be difficult to get them all pointed in the same direction (ie back to the need for technical leadership).

I recommend Chapter 12 of Applied Software Architecture for guidance on your question. The list of headings gives a good idea of its advice: Creating a vision, the architect as key technical consultant, the architect makes decisions, the architect coaches, the architect coordinates, the architect implements, the architect advocates. The 97 Things book you mention is more of a collection of pearls of wisdom rather than a cohesive guide to architecture.

George Fairbanks, Author of Just Enough Software Architecture

I am very eager to learn in depth OOP concepts and most importantly how they can be applied in "real life". So far, I have read many references and many tutorials online but they all lack something: They do not provide a way to fully understand how object oriented programming can be truly used. In fact, it seems that most tutorial focus on OOP "syntax" as opposed to "the art of OOP design". Since OOP is a set of concept/idea/best practice in thinking about a problem and tackling that problem in a way to allow a better productivity I really want more. I want something to help me think as an "OOP designer" and not an "OOP programmer". Can someone provide with me a resource (preferably an online resource) that actually provides a non trivial example on how to apply OOP? Although I am aware that OOP is language agnostic, I would prefer examples in C#.

I'm kind of new to the design patterns concept.
C# is my primary programming language. (I use VB from time to time). I don't want to write sloppy code which is inflexible, not extendable and buggy.
Whenever I see a design pattern in action, I enjoy the logic behind it and understand it well, But unfortunately, I'm having trouble implementing them in my projects.

You see, there are a lot of design patterns (120+ I think) and I am sort of lost among them when I want to decide which one to use.
When it comes to use them in action, I have no idea what to choose.
All I get from tutorials are some fairly simple code snippets which is far away from the production environment. except DDD pattern which I have managed to learn it well since There are at least 2 good books and many resources about it.

Now my question:
Is there anywhere that I can find some real samples using various design patterns? At least some "more practical" samples. Do you know anywhere that I can find such books/samples/resources for other patterns as well?
Thanks.

I'd start with the Head First Design Patterns book. It's not nearly as complicated as some of the other books and is meant to be a learning experience instead of a reference.

Much better for learning from scratch in my opinion. Head First books are pretty good about presenting the material in interesting ways and do a nice job of keeping you interested. This book also tries to tie in each pattern to a pseudo real-life example. Their examples might not be pertinent to what you are working on, but they at least deal with the same types of issues as real world problems (I think the first example deals with writing a duck simulation video game).

Also Head First Design Patterns focuses on cramming your brain with as many patterns as possible so you can recognize when you are in a situation to use one and be well equipped enough to at least get started. This is where a specific reference, such as the GoF book might come in handy.

However, keep in mind that Head First books typically focus on complete beginners. Their books don't make for good learning materials after you reach the intermediate stage in a given topic.

I still feel like the original gang of four Design Patterns book is the best way to learn this. The focus isn't on using the pattern in a specific language, or a specific place, but really describing why the patterns exist.

Once you truly understand why the patterns exist (not just how they work), using them in your own production code comes naturally.

There are countless examples on the internet all you have to do is search. As far as books, I would recommend "Design Patterns: Elements of Reusable Object-Oriented Software"

Enjoy!

Understanding of design patterns comes with time and experience. Unless you are very talented, in the beginning you'll probably write code that could be structured more efficiently and you wont even notice. Don't worry about that too much.

The thing with design patterns is learning to see their benefit. The particular shape of a pattern usually has very definite reasons. Learning to use a pattern is easy once you have figured out the reasons why organizing code that way is beneficial. Ask questions, set up hypotheses, experiment and see if you were right.

For reading, I'd suggest Design Patterns Explained and the SourceMaking site Matthieu suggested is also good.

Recently I came about this concept of Design Patterns, and felt really enthusiastic about it. Can you guys suggest some resources that help me dive into Design Patterns?

You know, for me, one of the best books out there is Head First Design Patterns. I personally like the style that they use to communicate the material.

The gang of four design patterns book is the standard. I recommend it if you're comfortable with C++.

Head first design patterns is good too, especially if you like visual aids and want to feel like you're learning design patterns in a '50s diner. Examples are in Java.

There are sometimes multiple ways to implement patterns in a given programming language (for example see this discussion of options for implementing the Singleton pattern in C#), so it might be worth getting one book to succinctly describe the common patterns, and another to suggest the best way to implement them in your favorite language.

Martin Fowler's website has plenty of information: http://martinfowler.com/articles.html. Much of this is covered also in his book, Patterns of Enterprise Application Architecture.

I find Design Patterns Explained to be a good introductory text. The Gang of Four book is a reference for those who already understand patterns.

Wikipedia, the Gang of Four book, and if you're specifically interested in C# implementations there's a decent site here.

I am looking for a resource/book suggestion on more effectively writing software. I just finished a couple python courses, c++, and data structures, and I know the basics of how to program now, but I have room for improvement. I would say I have about 100 hours of experience. I am looking for where to go from here... the goal being building my coding skill.

I don't want a book that is just for reading but a book with concrete examples I can learn from. I think my biggest problem is I've made up my own design methodologies and written all my code myself, and I need to expand my horizons to see how other people do it.

I am a beginner programmer (python and c++), and I feel I am spending way too much time debugging and refactoring my code and teaching myself design methods. My longest project has been 500 LOC, and I need a good book preferably with concrete examples, rather than reinventing the wheel myself. The highest priority thing I need is on designing software. I've heard various talks about the gang of four book. Is that something I should look into at this point?

I am learning a lot for certain, but I think my progress would be much faster if I could study from a well written book. Everything I have learned so far has been "in order to finish my project" for other classes, and I would like to become more proficient at coding. I imagine my eventual job will involve significant aspects of coding.

Thank you for taking the time to answer or discuss this open ended question.

edit: is there an equivalent list for python? -- The Definitive C++ Book Guide and List

Stay away from the GoF book in the beginning. The book that really helped me to get off the ground was the much easier to digest ...

http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=pd_sim_b_20

It is a gentle primer for the GoF book. This will get you in the right mindset and provides useful information for any OO language. Best of luck.

I am looking for a book which can teach OOP concepts using c++ . Could you guys please suggest me some books.

The best way of learning OOP is by learning Design Patterns. I started out with the book Design Patterns Explained. However, many people recommend Head First Design Patterns, so that's probably a good choice too, even though it illustrates the concepts using the Java programming language.

Okay, I'm biting the bullet and deciding to get into the whole Microsoft/C#/.NET culture and I'm going to do this by putting together a simple (hah!) application.

It will basically be an application in which I want to store images and associate with them other optional things.

It must be able to import images from the filesystem (and hopefully camera/scanner) then allow the user to add text, audio and other information.

I plan to store the images and auxillary information into a database. What the application will do with said data isn't important (yet).

Keep in mind I know absolutely nothing about C# or .NET although, as an old codger, I know a great deal about many other things and will regale/bore you with stories and anecdotes until you quietly slip away :-)

What are the first steps to take in developing such an application? I've already set out UI layouts and likely process flows although it may be that the development environment dictates changes.

Development environment is currently XP SP3 + VS2008 (though I can upgrade if absolutely necessary).

What should I be looking at as the first step? Are there any gotchas I should be looking out for?

My $0,02:

a) Get to know the platform a bit, types, collections, events/delegates(/lambdas), etc etc

b) Dive into WPF

c) Learn about database connectivity (LINQ2SQL or NHibernate (or ....)

d) Learn about the MVVM pattern to get to deliver solid wpf applications, doing so forces you to dive deeper into the workings of WPF (routed commands, tunneling/bubbleing etc)

e) Learn more about patterns to get a more solid grasp of OO (this: http://www.amazon.com/Design-Patterns-Explained-Perspective-Object-Oriented/dp/0321247140/ref=sr_1_1?ie=UTF8&s=books&qid=1276066663&sr=8-1 is an absolute pearl for that)

f) etc

Hi I am a newbie to C++ reading the C++ concepts...............and I am unable to comprehend the data hiding in the sense how it would be used practically or in real time.

question : As I know data hiding would implemented in C++ to hide the actual data being used behind the scenes in a programm suppose by declaring some datas private in a class. when a C++ program is made and compiled ....consider an example of of some game, the executable file (.exe or nay other executale in unix) would be given to the user?

so here what I am confused about? now where is my data hiding?? when the user is using the executable(.exe) because I my opinion .exe cannot be read or opened by the user to see the contents of the file anyway.. even if I declare all my variables public...still the data is hidden because the user just has the .exe file, which can't be read or manipulated by the user?

Please suggest guys?? give some feedback where I am thinking wrong

You need allot more than anyone can type in this short forum. I would suggest the book:

Design Patterns Explained: A New Perspective on Object-Oriented Design (2nd Edition)

It'll explain what the purpose of various elements of Object Oriented design are. For instance, what is encapsulation and why do you use it? And what is it you're actually encapsulating?

I'm trying to re-factor a code base, and there is some common functionality among unrelated classes that I'd love to unite. I would like to add that functionality in common base class, but I'm not sure if it's clean and good approach.

Say I have CMyWnd class and CMyDialogEx class, both different, so they cannot inherit from one base class. I want to add a button to both classes and add the message handlers to both classes as well.

So I'd like to do something like this:

CMyWnd : public CWnd, public COnOkBtnFunctionality, public COnCancelBtnFunctionality
CMyDialogEx: public CWnd, public COnOkBtnFunctionality

Where COnOkBtnFunctionality would define CButton m_buttonOk, and all the afx_msg functions it should have. And so on.

Is this approach doable/good? Or are there better patterns I should resort to?

Composition would be the right design decision; do not inherit.

If you have a special type of button that can be reused, create one: class MyButton : public CButton

If MyButton need access to methods from CMyDialogEx and CMyWnd, extract the common methods in a virtual class (strategy pattern) and derive from it. You can use the MyButton's constructor to place the instance of virtual class, so MyButton's methods can access the real implementation.

I can recommend Alan's and James's book Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):

alt text

It's a great book about has-a and is-a decissions, including cohesion and coupling in object-oriented design.

I study GoF Design Patterns book and have Martin Fowler's PoEAA book in list. (I also have Judith Bishop's book which I personally do not like.) But there are more patterns, such as Delegation pattern. What is its origin? Are there other patterns not mentioned in these books? Are there other "must read" books or online resources on this topic?

Design Patterns: Elements of Reusable Object-Oriented Software and The Design of Everyday Things are very good books. I especially recommend the former for its intuitive read.

Are there other patterns not mentioned in these books?

Definitely. The GoF patterns are kind of the grandaddies of it all, and fairly general, but you can have domain-specific patterns too. Like Fowler's PoEAA, as you mentioned. Or design patterns for embedded systems. But also more domain-specific than that, like Fowler's book on Analysis Patterns, which has financial and health care related patterns. Or patterns for avionics systems, like in the link available here at the Hillside Patterns Catalog.

What is its origin?

If you mean what is the origin of the Delegation pattern, I dunno, but someone has asked a similar question here.

Are there other "must read" books or online resources on this topic?

The amusingly-named "PLoP" conferences (Pattern Languages of Program Design) are the first place a fair few patterns are aired I believe.

There's a PLoP journal as well: Transactions on Pattern Languages of Programming.

I found Design Patterns Explained to be quite useful in explaining some of the original thinking behind the Gang of Four patterns. It's an explanation as opposed to a reference.

In addition to the PluralSight catalog mentioned elsewhere, NetObjectives have some great resources on patterns (and principles in general), particularly their series of webinars.

Whilst there are many good examples on this forum that contain examples of coupling and cohesion, I am struggling to apply it to my code fully. I can identify parts in my code that may need changing. Would any Java experts be able to take a look at my code and explain to me what aspects are good and bad. I don't mind changing it myself at all. It's just that many people seem to disagree with each other and I'm finding it hard to actually understand what principles to follow...

I can recommend Alan's and James's book Design Patterns explained -- A new perspective on object-oriented design (ISBN-13: 978-0321247148):

Cover: Design Patterns explained -- A new perspective on object-oriented design

It's a great book about has-a and is-a decissions, including cohesion and coupling in object-oriented design.

In software engineering, a design pattern is a general reusable solution to a commonly occurring problem within a given context in software design.

A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved. Many patterns imply object-orientation or more generally mutable state, and so may not be as applicable in functional programming languages, in which data is immutable or treated as such.

Gang of Four design patterns

Concurrency patterns

Other patterns

Useful links

Books