What do you recommend reading when learning design patterns. Currently I am thinking about reading: - Agile Software Development: Principles, Patterns, and Practices - Design Patterns Explained - VB 6.0 and VB .Net Design Patterns (skipping the VB 6.0 part) - Professional Design Patterns in VB .Net - Thé DP book (GOF)

I would like to read them all, but I do not own some kind of magic time-freeze amulet, so feel free to give recommendations what to read from above or not above.

If you have been working with OOP for a while without the knowledge of DP then a book on design patterns will just teach you the names of the things that you have been doing before.

Here is some of the design patterns that i encounter and use the most. Adapter pattern. Bridge pattern. Facade pattern. Simple Factory. Abstract Factory. Factory method. Singleton. Proto type.

wayne wrote:

If you have been working with OOP for a while without the knowledge of DP then a book on design patterns will just teach you the names of the things that you have been doing before.

Well, I've been doing OOP for two years now and pretty much know how it works. If you keep designing in the way of encapsulation, inheritance, polymorphism and data hiding, your code will become and remain flexible/dynamic/easy to maintain. But still, I often find myself blocking myself in my coding, by thinking to much about the design. My code really needs to be "outstanding". If not, I just stare at it, figuring out, how to do it better. About a year ago, I was doing this "staring-thing" to globals. I didn't like the way they were, so I started to ask people how they would solve it. As result I implented a sort of singleton. If I now think: "I need a global point of access", I immediatly go for this pattern: Perhaps you could say in this case, that I am thinking in a pattern. And I like this way of thinking, because you don't have to think (much). I also find it to boost up your thinking: when thinking about something I often use words. For example, if I am thinking about creating a composition, I could think about the word "composition" rather then think about eg "a class with elements where the structure contains data objects or other structures". Or even worse, thinking about the naming and types of these data objects. By thinking just composition, I already define a set of rules of how it should be implented. I hope some day I will have definition for all the problems I customer ask me . Then when he is speaking, I would just write some "pattern names" and thereby shorten his 12 twelve page story to a small 1 or 2 pages. And yes... I do think DP's will allow me to at least define some set of rules .

BlueCell wrote:

What do you recommend reading when learning design patterns. Currently I am thinking about reading: - Agile Software Development: Principles, Patterns, and Practices - Design Patterns Explained - VB 6.0 and VB .Net Design Patterns (skipping the VB 6.0 part) - Professional Design Patterns in VB .Net - Thé DP book (GOF)

I would like to read them all, but I do not own some kind of magic time-freeze amulet, so feel free to give recommendations what to read from above or not above.

Patterns are good but only as a solution to a problem, not as a design building block. This means that you have to first understand the problem, then look at patterns to check if these solve the problem you have and then apply a pattern. Avoid thinking in patterns, as that will make you design applications 'just because the patterns tell me to do so', without knowing if you even have the problem solved by the pattern. This can lead to implications in your design, for example: you design the application way too complicated (look at a random DotNet application block released by microsoft), falling into anti-patterns.

Otis wrote:

Patterns are good but only as a solution to a problem, not as a design building block. This means that you have to first understand the problem, then look at patterns to check if these solve the problem you have and then apply a pattern. Avoid thinking in patterns, as that will make you design applications 'just because the patterns tell me to do so', without knowing if you even have the problem solved by the pattern. This can lead to implications in your design, for example: you design the application way too complicated (look at a random DotNet application block released by microsoft), falling into anti-patterns.

I see your point. By thinking in DP's you limit yourself in the description (of a problem). By saying, "it is a singleton", you never know if this is true, because "singleton" is your only description of the problem. I now also see that DP's should only be a solution, because by knowing exactly what the problem is, you also know what the solution is. In other words, without knowing what a "singleton" as solution is, you can still find what the solution should look like (by looking at the discription of the problem) and therefore "know" what is meant with a "singleton".

Still I am very interrested in reading more on DP's. Knowing how other people implent their solutions is always good, is it not? As for which book to pick, I think I'll just pick one which looks good to me...

I read a book on design pattern about 2 weeks ago.It was called _ Design Patterns Explained: A New Perspective on Object-Oriented Design by Alan Shalloway, James R. Trott_

I found it pretty easy to read and it showed practical examples

Frans hit the nail on the head.

As for my favorite DP books, Programming .NET Components by Oriley. Gives a good look at how to use interface based programming vs. thick inheritance models.

Design Patterns in C# by Steven John Metsker Patterns of Enterprise Application Architechture by Martin Fowler

Microsoft also has some OK documents in their patterns and practices section.